Named constructors

[Atila Neves]

On Thursday, 10 January 2019 at 11:40:38 UTC, evilrat wrote:
> On Thursday, 10 January 2019 at 10:50:24 UTC, Atila Neves wrote:
>> On Wednesday, 9 January 2019 at 17:46:52 UTC, H. S. Teoh wrote:
>>> On Wed, Jan 09, 2019 at 05:30:32PM +0000, Atila Neves via 
>>> Digitalmars-d wrote:
>>>> [...]
>>>
>>> +1. That's what the type system is for.  Dummy arguments are 
>>> NEVER a good idea unless there's a need for the API to be 
>>> uniform.
>>>
>>> It also makes the calling code self-documenting without 
>>> needing language support for named arguments:
>>>
>>> 	auto myPerson = Person(FirstName("John"), LastName("Doe"));
>>>
>>> rather than the opaque (and thus error-prone):
>>>
>>> 	// Bug 1234: hmm, is it first name first, or last name first?
>>> 	//auto myPerson = Person("Doe", "John");
>>> 	auto myPerson = Person("John", "Doe");
>>>
>>>
>>> T
>>
>> Fully in agreement. Now if only I write that library I've been 
>> meaning to that lets you pass parameters in any order if the 
>> types are right...
>
> For that I'd actually would prefer having a language support - 
> named parameters, like Python/C# does...

Language support isn't needed, and since this kind of feature 
doesn't play well with overloading...

What's the _real_ difference between 
`someFunc(firstName="Alice")` and `someFunc(FirstName("Alice"))`? 
The former saves one character? Is that really worth the cost of 
language support? I have a feeling a lot of feature requests 
neglect that each and every one of them has a cost, and there's 
only enough budget for so many.

>
>    void someFunc(string firstName, string lastName, int age);
>
>    // use it
>    someFunc(age=30, firstName="John", lastName="Doe");
>
> That also solves the problem when we have some default 
> parameters and only want to pass one of them from middle/end of 
> the list.

This can be solved with a library, which I mentioned above I want 
to write. You can do this today awkwardly by using a variadic 
template and reflecting.