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

[rikki cattermole]

On 09/04/2019 7:21 PM, Daniel N wrote:
> On Monday, 8 April 2019 at 23:09:31 UTC, bauss wrote:
>> On Monday, 8 April 2019 at 16:33:36 UTC, Yuxuan Shui wrote:
>>> The interpretation of his proposal suggested by you (i.e. this call 
>>> is ambiguous) is obviously a possible one, but not necessarily what 
>>> Walter intended.
>>
>> And in that case it doesn't matter really because it's not a situation 
>> that would ever happen.
> 
> Even if 'D' somehow defined that this is valid D code:
> 
> void x(int p1) {}
> void x(int p2) {}
> 
> Some linkers would refuse to link it (including our own OPTLINK and the 
> MS linker), since D has to support a great number of different linkers, 
> we cannot mandate that all linkers in the world need to have a special 
> force flag to override and link anyway just to be compatible with the 
> above construct.
> 
> For that reason I don't think Walters comment is open for 
> interpretation, the above program is ill-formed.
> 
> Even if, for compilation speed optimization reasons, the compiler might 
> not be required to issue a diagnostic, it still doesn't change the fact 
> that the program is ill-formed, another conforming D compiler should be 
> allowed to reject that code.

In DIP 1020 I did not want or allowed named parameters to affect name 
mangling or lookup. Its a very simple solution, but it solves so many 
problems.