Index: doc/proposals/named-parameters.md
===================================================================
--- doc/proposals/named-parameters.md	(revision 6740533ecd065da4a4b2d8b9ab5bd7ba6ed93ed4)
+++ doc/proposals/named-parameters.md	(revision 3a7cd15cac22788f672532e5ed458cd83012ee3a)
@@ -17,4 +17,12 @@
 +   Ada - Named Association
 +   C - Designators (limited)
+
+Status of Proposal
+------------------
+This proposal is "an examination", there are still issues to solve. Including
+syntax, the exact rules of how forward declarations and definitions must
+relate. It does break through a major problem C had, in that names of
+parameters are not consistent. By using C parameters as positional-only
+parameters so that does not cause issues.
 
 Overview of New Features
@@ -69,4 +77,8 @@
 considered, but most can cleanly be removed.
 
+Note that matching arguments to parameters is tied up into matching calls
+with definitions, and requires arguments to be resolved, and so has to happen
+within the resolver.
+
 First, the positional parameters have to be sorted out.
 
@@ -125,4 +137,76 @@
 generalized to function calls (not even initializers we resolve as functions)
 because of overloading.
+
+Syntax Options
+--------------
+The syntax suggested above both does not work and may be incomplete. It was
+good enough for the initial descussion but will need some further work.
+
+The issue with the above syntax is that `TYPE .NAME` can look like a
+qualified type to the parser. Considering how wide spreak the qualified type
+syntax is, it could be changed. Here are some syntax suggestions:
+
+Named Argument: `.NAME = EXPR`
+Named (Required) Parameter: `TYPE .NAME`
+Named (Optional) Parameter: `TYPE .NAME = EXPR`
+
+The first suggestion is an attempt to use C designator syntax as the name
+syntax. A named parameter is now a generialization of designators. The
+parameters are added into a function's parameter list.
+
+	`@NAME = EXPR` | `TYPE @NAME` | `TYPE @NAME = EXPR`
+	`?NAME = EXPR` | `TYPE ?NAME` | `TYPE ?NAME = EXPR`
+
+Some other characters that could be used in the same syntax. The `@` symbol
+hints at some location/address. Peter was just excited about `?` but it is an
+little used symbol and parses at this time. This does weaken the connection
+with designators, which was the main advantage of the designator like syntax.
+
+Named Argument: `NAME: EXPR`
+Named Parameter: `NAME: TYPE NAME0` | `TYPE NAME:`
+
+Another bit of C syntax we could try to adapt to named parameters are labels.
+We reuse the label syntax used at the statement level at the expression level
+to note where (with which parameter) this expression goes.
+
+This syntax (the first option for the named parameter) is also has an example
+of a possible (but not popular) feature where the parameter name (the
+identifier used inside the function) and the parameter label (the identifier
+used at the call site) are independent.
+
+	`PARAMS;PARAMS` | `;PARAMS`
+
+Another way to describe the type of parameters is by dividing the parameter
+list into sections. Here we replace a `,` separator between two parameters,
+with a single (per parameter list) `;` that marks the end of the positional
+parameters. The argument syntax would have to be borrowed from some other
+example (such as the designator one, where the parameter is the problematic
+one for the parser), possibly with another `;` separator to add context.
+Also, the `;` separator can appear at the beginning of the parameter list as
+well if all parameters are positional.
+
+Named Argument: `NAME @= EXPR`
+Named Parameter: `TYPE NAME @= EXPR`
+
+Another syntax to modify is assignment, with a special "assign to parameter"
+operator (although structurally it
+
+	`NAME := EXPR` | `TYPE NAME := EXPR`
+
+Like with the variations of the designator-like syntax, the separator could
+be changed out, so that symbol can be used as the identifying feature of the
+named argument.
+
+The incompleteness is that most of these just have one more parameter
+declaration. That is, there is only syntax for positional-or-named parameters
+or named-only parameters, so far it has been named-only. Positional-only
+parameters are "locked" to the C syntax for compatability reasons. Supporting
+both cases gives additional flexibility and could be done by combining two
+of the above syntax (or by altering one).
+
+	void call(int position, char .position_or_name = a; double .name = b);
+
+Note, that C-style autogenerated constructors would still be positional or
+named parameters for compatability.
 
 Run-time Implementation