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

[rikki cattermole]

On 11/09/2019 1:27 AM, a11e99z wrote:
> On Tuesday, 10 September 2019 at 12:37:27 UTC, rikki cattermole wrote:
>> On 10/09/2019 11:51 PM, SashaGreat wrote:
> 
> I have addition:
> 
> @named("arg") should accept string as named param name:
> when arg is absent - use real param name
> when arg is exists - use "arg" as param name for named param (phew!)
> 
> void func( @named("longBeautyName") int val ) {
>    // I can use "val" here
>    someGlobal = val;
> }
> 
> // but when u use named param u should set longBeautyName
> func( longBeautyName: 123 );

I quite like the syntax for this semantic.

However I am unsure of its beneficial nature.

This semantic would cover renaming and give greater freedom to the API 
creator, but it would require some changes that complicates 
introspection even in the most basic of use cases.

Once function bodies are removed (.di files), these renames wouldn't 
matter. You can just call the parameter whatever you want.

I am unsure how it would effect the arguments passing since I am not 
defining that (should be left to a compiler writer to decide that, 
either here or during implementation).

There is an alternative to this proposal which I prefer and that is to 
allow implicit construction of structs (with constructor defined to 
support passed in type). That would handle both deprecated names and 
types more uniformly but that would require another DIP.