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

[jmh530]

On Tuesday, 17 September 2019 at 12:37:50 UTC, rikki cattermole 
wrote:
> [snip]
>
> It does not no.
>
> My current design which I created as a backup to DIP1020 which 
> supports his, I do not believe fits in with the current design 
> of signatures.
>
> I.e.
>
> struct Foo(public T) {
> }
>
> static asssert(Foo!(T: int).T == int);

I think I'm starting to understand your signatures idea from this.

That being said, I think this would be a lot simpler if types 
were first class citizens. If they were, then you could easily 
return types from functions. So instead of your Foo above, you 
could have

struct Foo(T) {
     type T() {
         return T;
     }
}

You could write mixins to automatically generate those functions 
pretty easily as a first step.

Above you have an example with

> signature InputRange(@named ElementType) {
> 	...
> }

But I think this would have the same issue as your @named syntax.