- Augment example ``struct Map(@named alias Function, @named InputType, @named ElementType)`` with a less exagerated signature.

```d
auto map(alias Function, InputType)(InputType input) {
	return Map!(Function, InputType)(input);
}

struct Map(alias Function, InputType,
	@named ElementType = ElementType!InputType)
```

- Python's parameter syntax is not ``identifier = Parameter`` it is ``** Identifier`` and that is only for variadic or unknown keyword arguments, all parameters can be passed in as named.
- C# does not have opt-in syntax for parameters.
- ``It is the author's opinion that the is expression is heavily overloaded and doing too much. It should be possible to access the names of named template parameters outside of an instantiated template, but it should be done with a mechanism other than the is expression.`` is potentially too vein.

	Add example

	```d
	void func() {
	    alias Type = Foo!int;

	    static if (is(Type : Foo!T, T)) {
	    }
	}

	struct Foo(Type) {
	}
	```

	If the template parameter of Foo was @named, then T in the static if would have to match the name of the parameter.
	Which could conflict and the user would be forced to change other parts of the code and not use a name that suits them.
	This is a consequence of named parameters being non-positional.
- Walter's proposal should have a section dedicated to it in the form of 'alternative solutions'
- Can you discuss the pros and cons of marking each individual parameter vs marking functions?
- ``The side effect of this decision is that named parameters must be opt-in. Parameters must be marked as accepting named arguments, otherwise there will be no way to determine which overload to resolve.``
	Needs to be made clearer that it is related to the previous paragraph.
- ``The @named attribute prevents clashes with other existing language``
	Demonstrate what other syntaxes could produce (e.g. T:V vs T::V).
- subset vs sublist, make it clear at both locations what is meant.
- ``Overload resolution for symbols (for function and template``
	Use std.traits isInstanceOf as example of code that will need to be changed to accomedate named parameters.
- Semantics heading can get at least one more sub heading split out from it
- Non-eponymous members of eponymous templates are currently inaccessible from outside the template body, so this will require changes to D's name lookup rules.
- Add new section comparing and contrasting reordering rules
- A named parameter requires a name, specify this.
- In place struct initialization syntax: "Just use the syntax I proposed for named parameters. The feature will be disabled if the struct has constructor(s) for it, as now." - Walter
- Make it clear that @named is an attribute (and hence can't be defined for UDA use).