DIP 1030--Named Arguments--Community Review Round 1 Discussion

[Steven Schveighoffer]

On 2/11/20 9:07 AM, Adam D. Ruppe wrote:
> On Tuesday, 11 February 2020 at 13:52:35 UTC, Steven Schveighoffer wrote:
>> Is there a plan to mitigate this limitation?
> 
> I wrote about this in github comments when the dip pr was first opened:
> 
> https://github.com/dlang/DIPs/pull/168#discussion_r324481363
> 
> lol actually you were the person to push back hardest! 

ha, I just pushed back on the idea of a custom struct coming in and the 
template having to deal with that in a special way ;)

But my thoughts have evolved on the importance of this. I think it makes 
the DIP not worth it if we can't capture those calls properly.

Note also: if the template parameters names are part of the tuple type, 
and therefore part of the template instantiation, we have an actual path 
to deprecations as well:

Date makeDate(int year, int month, int day) {...}

deprecated("Use better names please")
auto makeDate(T...)(T args) if (containsArgName!("a", T) || 
containsArgName!("b", T) || containsArgName!("c", T))
{
    auto makeDateImpl(int a, int b, int c)
    {
        // remove names
        return .makeDate(a, b, c);
    }
    return makeDateImpl(args);
}

> __traits(identifier) on the template param is a solid possibility, and 
> the other push back is maybe making it opt-in... but with your 
> __traits(identifier) add on.... no need for my weird struct thingy.
> 
> So basically the template variadic params would then work identically to 
> the __parameters result we already have (probably including the slice 
> technique lol). There's precedent!
> 
> That should absolutely work. And could be done right now to solve this 
> in full - with the names being part of the variadic tuple it would 
> forward to calls as well. I like it a lot.
> 
> But I still think this DIP as-is is an OK addition without it. We can 
> always remove the T... limitation later as well.

I think while it doesn't break currently existing code, it breaks the 
*intention* of code. Something that intends to be a perfect forward of 
an API can no longer EVER claim that. Manu is right, a whole lot of code 
out there exists solely to massage APIs, adding one nuance here or there.

-Steve