DIP 1020--Named Parameters--Community Review Round 1

[rikki cattermole]

As the author of this DIP, I have created a list of actionable items I 
expect to include in the next iteration of the DIP.

If I have missed something you wish to be included please reply to this 
post.

In the next few days I expect to write a (short) set of responses so 
that we can discuss it further. My responses tonight will be directed at 
non-reoccurring items between the posts.

- Angle brackets, may be hard to find given relationship with templates
   Potential solutions include ``@named``
- External access of template parameters externally needs justification
- Interaction with eponymous templates, invalid
- "Future proposals" sections should probably have a full rewrite to 
indicate its for recognizing desirable semantics that are out of scope.
- Not in competition with in place struct initialization, different purposes
- More headings (break down behavior)
- Reorder of arguments does not change at symbol site, only at the 
argument side
- Overload resolution code is flawed with illegal code
- Compare and contrast example code
- Logging case demonstrates that for functions unnamed should be the 
default API wise
- Duplicate naming is bad, flagging of a parameter as named is better