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

jmh530 john.michael.hall at gmail.com
Tue Sep 17 13:13:03 UTC 2019

On Tuesday, 17 September 2019 at 12:37:50 UTC, rikki cattermole 
> [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.

More information about the Digitalmars-d mailing list