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

rikki cattermole rikki at cattermole.co.nz
Tue Sep 17 13:36:59 UTC 2019

On 18/09/2019 1:13 AM, jmh530 wrote:
> 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.

So with signatures you essentially need a separate parameter type which 
says: will probably be inferred from something but can be set by the 
user if they really need to.

In your above example, I suspect it will have name collisions as-is.

Sadly I don't see a way to make these parameters actually part of the 
body of a signature where they belong. They are a property of a 
signature just like sizeof is, no difference between them. But they are 
template parameters too. Not great for syntax when ``alias T;`` is 
already legal.

> Above you have an example with
>> signature InputRange(@named ElementType) {
>>     ...
>> }
> But I think this would have the same issue as your @named syntax.

That is an example using known semantics + syntax, it is DIP 1020 ;)

More information about the Digitalmars-d mailing list