Named constructors

[rikki cattermole]

On 12/01/2019 1:57 AM, JN wrote:
> On Friday, 11 January 2019 at 11:25:39 UTC, rikki cattermole wrote:
>> On 12/01/2019 12:24 AM, JN wrote:
>>> On Friday, 11 January 2019 at 07:53:56 UTC, rikki cattermole wrote:
>>>> On 11/01/2019 3:35 AM, JN wrote:
>>>>> Also, named/keyword arguments shouldn't be an issue in regards to 
>>>>> overloading and argument order. Every language I know that has 
>>>>> named/kw arguments allows either only keyword arguments or keywords 
>>>>> arguments at the end of the argument list. You can do:
>>>>>
>>>>> foo(x=10)
>>>>> foo(10, 20, z=30)
>>>>>
>>>>> but you can't do:
>>>>>
>>>>> foo(x=10, 20)
>>>>>
>>>>> because it'd be ambiguous.
>>>>
>>>> Actually every example there is ambiguous and problematic in D.
>>>> It conflicts with AssignExpression which is identical in syntax and 
>>>> usage!
>>>
>>> well, it's because I used the equality sign, languages like C# use :,
>>>
>>> I guess:
>>>
>>> foo(x:10, 20)
>>>
>>> would be better?
>>
>> Yup no ambiguity, that is why my named parameter DIP uses it :)
> 
> Is there even any usecase for AssignExpression within function 
> parameters list? I imagine if (ptr = getPtr()) stuff can be useful (but 
> still kind of risky if you actually intended ==), but putting 
> assignments in function calls seems like could be disallowed without any 
> negative effects.

Our grammar looks very similar to C's in this area.
In both languages there are no assignment statements, only assignment 
expressions with expressions promoted to statements directly.

While we can make using AssignExpression like this illegal, it does make 
transition and porting to D harder from C. Perhaps Walter might be open 
to this? But personally while I might hate it, I don't think that it 
would be a good idea to remove it then use the same syntax for something 
else.

So use case? C does it like this. That should be enough to keep it as is 
sadly.