On 2016-05-25 11:24, Daniel N wrote:

> From an end-user perspective I find it reasonable to expect that an API
> which takes lambda:s works consistently for both below examples. i.e. if
> we support one we should support the other.
>
> [1] fun!(     x  => y)
> [2] fun!((int x) => y)
>
> Currently I just copy/paste the fix to ParameterIdentifierTuple
> everywhere as the needed primitives already exist.
>
> Removing the already existing primitives now is imho too late, as it
> breaks code, which sometimes is OK, but this time there's no clear
> solution how to rewrite the broken code.
>
> Unfinished Library based Named-parameters proof-of-concept:
> (yes, I know. It needs to be updated to handle case [2])
> https://dpaste.dzfl.pl/ae55de677f86
>
> /vote open floodgates for introspection, capitalizing on the strengths
> of D.

I don't think this is the right approach. I think the correct approach is to allow introspection of template parameters [1]. That would allow to get the parameter names without having to instantiate the template.

ParameterIdentifierTuple can hopefully be updated to take advantage of this feature when it's available in compiler without requiring to change the API of ParameterIdentifierTuple.

[1] https://github.com/dlang/dmd/pull/5201

-- 
/Jacob Carlborg

On Wednesday, 25 May 2016 at 11:22:41 UTC, Jacob Carlborg wrote:
> On 2016-05-25 11:24, Daniel N wrote:
>
> ParameterIdentifierTuple can hopefully be updated to take advantage of this feature when it's available in compiler without requiring to change the API of ParameterIdentifierTuple.
>
> [1] https://github.com/dlang/dmd/pull/5201

Issue9608 is good too, but insufficient.

import std.traits;
static assert(__traits(isTemplate, a => 0));
static assert(!__traits(isTemplate, (int a) => 0));

The 2nd case can't be solved by 9608 since it's about introspecting templates and "(int a) => 0)" is no template.

On Tuesday, 24 May 2016 at 16:00:32 UTC, Andrei Alexandrescu wrote:
> Apparently it can be made to work with non-templates as well, see https://dpaste.dzfl.pl/c4b7a8b6978b.

Oh, that's the buggy area. The compiler keeps parameter names for runtime delegates... but it also reuses the structures. Thus, in simple examples, it works, but outside that it becomes very unreliable.

Parameter names are NOT part of a delegate's type. But an alias parameter to a template is a different story!

On Wednesday, 25 May 2016 at 09:24:31 UTC, Daniel N wrote:
> From an end-user perspective I find it reasonable to expect that an API which takes lambda:s works consistently for both below examples. i.e. if we support one we should support the other.
>
> [1] fun!(     x  => y)
> [2] fun!((int x) => y)

Those are indeed both can work to fetch names, though they aren't exactly the same since the first one is a template and the second one isn't. The technique is slightly different right now, but both doable (and I have no objection to unifying the techniques)

The big difference I'm talking about is passing them as an alias argument vs as a runtime argument. Runtime function pointers lose many of the introspection capabilities of compile time alias arguments (well, runtime args still can pretend to give you names, but you'll find it doesn't actually work very well).

From the looks of the Phobos PR too, it looks like some of the commentators conflated the two issues too: template vs non-template isn't the same as alias vs delegate.

On 2016-05-25 13:57, Daniel N wrote:

> Issue9608 is good too, but insufficient.
>
> import std.traits;
> static assert(__traits(isTemplate, a => 0));
> static assert(!__traits(isTemplate, (int a) => 0));
>
> The 2nd case can't be solved by 9608 since it's about introspecting
> templates and "(int a) => 0)" is no template.

Hmm, I though the second case was already possible, but I see now that it isn't.

-- 
/Jacob Carlborg

On Wednesday, 25 May 2016 at 11:22:41 UTC, Jacob Carlborg wrote:
> I don't think this is the right approach. I think the correct approach is to allow introspection of template parameters [1]. That would allow to get the parameter names without having to instantiate the template.

Is that true? I don't claim to know exactly how the compiler works, but given a template lambda:

foo => 3

Doesn't it generate something like the following?

template __lambda10293(T)
{
    <deduced return type> __lambda10293(T foo)
    {
        return 3;
    }
}

In that case, "foo" is not a template parameter, but a runtime parameter, so template parameter introspection would not help in this case.

On 2016-05-25 20:55, Meta wrote:

> Is that true? I don't claim to know exactly how the compiler works, but
> given a template lambda:
>
> foo => 3
>
> Doesn't it generate something like the following?
>
> template __lambda10293(T)
> {
>      <deduced return type> __lambda10293(T foo)
>      {
>          return 3;
>      }
> }
>
> In that case, "foo" is not a template parameter, but a runtime
> parameter, so template parameter introspection would not help in this case.
>

Well, a runtime parameter in a template then :)

-- 
/Jacob Carlborg

On Monday, 23 May 2016 at 19:00:40 UTC, Adam D. Ruppe wrote:
> Have I gone completely mad?!?!

Yes, though what does it have to do with this thread? :D

This is by far the most appealing way to implement named arguments that I've seen so far:

https://github.com/CyberShadow/ae/blob/master/utils/meta/args.d

On Friday, 27 May 2016 at 18:10:59 UTC, Vladimir Panteleev wrote:
> On Monday, 23 May 2016 at 19:00:40 UTC, Adam D. Ruppe wrote:
>> Have I gone completely mad?!?!
>
> Yes, though what does it have to do with this thread? :D
>
> This is by far the most appealing way to implement named arguments that I've seen so far:
>
> https://github.com/CyberShadow/ae/blob/master/utils/meta/args.d

This is very nice... way more clean than I imagined possible.

On 5/27/16 10:17 PM, Taylor Hillegeist wrote:
> On Friday, 27 May 2016 at 18:10:59 UTC, Vladimir Panteleev wrote:
>> On Monday, 23 May 2016 at 19:00:40 UTC, Adam D. Ruppe wrote:
>>> Have I gone completely mad?!?!
>>
>> Yes, though what does it have to do with this thread? :D
>>
>> This is by far the most appealing way to implement named arguments
>> that I've seen so far:
>>
>> https://github.com/CyberShadow/ae/blob/master/utils/meta/args.d
>
> This is very nice... way more clean than I imagined possible.

s/args/make/g and we have a nice function for std.conv. -- Andrei