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

On Tuesday, 17 September 2019 at 13:36:59 UTC, rikki cattermole wrote:
> [snip]
>
> 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.
>
> [snip]

Would it help to use opDispatch? Maybe something like below (assuming types are first class objects):

struct Foo(T) {
    type opDispatch(string U)()
        if (is(T == mixin(U))
    {
        return mixin(U);
    }
}

On 18/09/2019 1:52 AM, jmh530 wrote:
> On Tuesday, 17 September 2019 at 13:36:59 UTC, rikki cattermole wrote:
>> [snip]
>>
>> 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.
>>
>> [snip]
> 
> Would it help to use opDispatch? Maybe something like below (assuming types are first class objects):
> 
> struct Foo(T) {
>      type opDispatch(string U)()
>          if (is(T == mixin(U))
>      {
>          return mixin(U);
>      }
> }

Yes.

But as a language feature I have no idea what first class types would do in D.

For example:

alias Foo(T) = T.U;

in long form:

template Foo(T) {
	alias Foo = T.U;
}

So we already have "functions" that return types+constants already.

On Tuesday, 17 September 2019 at 13:58:06 UTC, rikki cattermole wrote:
> [snip]
>
> But as a language feature I have no idea what first class types would do in D.
>
> For example:
>
> alias Foo(T) = T.U;
>
> in long form:
>
> template Foo(T) {
> 	alias Foo = T.U;
> }
>
> So we already have "functions" that return types+constants already.

I don't know if I would call that a function...but I see your point.

T.U doesn't work currently in this case of course.

On Tuesday, 10 September 2019 at 09:06:23 UTC, Mike Parker wrote:
> This is the feedback thread for the second round of Community Review for DIP 1020, "Named Parameters"

You're forbidding calling a function with a positional argument coming after a named argument, except when the order is exactly the same as in the function definition. I don't think that's a good idea, because it makes order of the named parameters relevant. That may make the function complex to ABI mangle, and prevents function definer from freely reordering named parameters afterwards. I think you should either:

-require named arguments to come last in the call (and perhaps the corresponding parameters in the function definition)
-allow a positional argument to come last in any case. The caller may stick named arguments anywhere in the argument list, only exception being that named parameter can't be passed by UFCS.

Otherwise I like this. The best named argument proposal in the reviews so far.

On 25/09/2019 3:49 AM, Dukc wrote:
> On Tuesday, 10 September 2019 at 09:06:23 UTC, Mike Parker wrote:
>> This is the feedback thread for the second round of Community Review for DIP 1020, "Named Parameters"
> 
> You're forbidding calling a function with a positional argument coming after a named argument, except when the order is exactly the same as in the function definition. I don't think that's a good idea, because it makes order of the named parameters relevant. That may make the function complex to ABI mangle, and prevents function definer from freely reordering named parameters afterwards. I think you should either:

That's not true.
The order is relative to the other named parameters except when no positional arguments follow.

This DIP does not change ABI mangling since named parameters do not get mangled (they also don't get considered for overload resolution so that makes it possible).

> -require named arguments to come last in the call (and perhaps the corresponding parameters in the function definition)
> -allow a positional argument to come last in any case. The caller may stick named arguments anywhere in the argument list, only exception being that named parameter can't be passed by UFCS.
> 
> Otherwise I like this. The best named argument proposal in the reviews so far.

Thanks, however Walter has killed this DIP so that's that I'm afraid.

On Tuesday, 24 September 2019 at 17:15:51 UTC, rikki cattermole wrote:
> That's not true.
> The order is relative to the other named parameters except when no positional arguments follow.

Hmm, sounds somewhat better. Well, the implementor can define the parameters last if he wants to be free to reorder afterwards.

>
> This DIP does not change ABI mangling since named parameters do not get mangled (they also don't get considered for overload resolution so that makes it possible).

They do not have to be mangled, but the implementor might want to generate a hash from named parameters to the mangling, to avoid linking to a function that has different named parameters.

>
> Thanks, however Walter has killed this DIP so that's that I'm afraid.

My symphaties. Ask Mike to mark the DIP postponed? Walter's DIP has not yet passed the reviews, so there's always the possibility that someone uncovers a major flaw. In that case, it's good to have a backup DIP.

On 25/09/2019 7:57 AM, Dukc wrote:
> On Tuesday, 24 September 2019 at 17:15:51 UTC, rikki cattermole wrote:
>> That's not true.
>> The order is relative to the other named parameters except when no positional arguments follow.
> 
> Hmm, sounds somewhat better. Well, the implementor can define the parameters last if he wants to be free to reorder afterwards.

We are mixing terminology I fear.

Parameter = declaration side
Argument = caller side

Parameters can be in any order.
Named arguments must remain in order of the named parameter list until the last unnamed argument. After that its any order.

>>
>> This DIP does not change ABI mangling since named parameters do not get mangled (they also don't get considered for overload resolution so that makes it possible).
> 
> They do not have to be mangled, but the implementor might want to generate a hash from named parameters to the mangling, to avoid linking to a function that has different named parameters.

I've considered this, there is no benefit. Mangling is not a safety feature. It only exists to make symbol overloading possible.

>>
>> Thanks, however Walter has killed this DIP so that's that I'm afraid.
> 
> My symphaties. Ask Mike to mark the DIP postponed? Walter's DIP has not yet passed the reviews, so there's always the possibility that someone uncovers a major flaw. In that case, it's good to have a backup DIP.

There shouldn't be any major issues with his.
Apart from one or two invasive changes which he is more than capable of implementing himself (and maybe the only one I would trust doing it) its pretty light on features.

On Tuesday, 24 September 2019 at 20:05:04 UTC, rikki cattermole wrote:
>> Ask Mike to mark the DIP postponed? Walter's DIP has not yet passed the reviews, so there's always the possibility that someone uncovers a major flaw. In that case, it's good to have a backup DIP.
>
> There shouldn't be any major issues with his.
> Apart from one or two invasive changes which he is more than capable of implementing himself (and maybe the only one I would trust doing it) its pretty light on features.

Regardless. A DIP may be fundamentally flawed even if it's implementable and does not break anything. It may close the door off from some important future change, or have some side-effect that's hard to see in advance. That's the very reason for this whole review process.