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

[rikki cattermole]

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 ;)