DMD 1.035 and 2.019 releases

[Bruno Medeiros]

Jarrett Billingsley wrote:
> On Mon, Sep 8, 2008 at 9:39 AM, Bruno Medeiros
> <brunodomedeiros+spam at com.gmail> wrote:
>> Jarrett Billingsley wrote:
>>> Now were you just reading off of
>>> http://d.puremagic.com/issues/show_bug.cgi?id=2170 or did you come to
>>> this conclusion independently ;)
>> I was reading that, and I must say, I didn't quite understand the reasoning
>> behind that named function parameters proposal.
> 
> Do you mean you don't understand the need for named function
> parameters, or you're not clear on the mechanism?
> 

I meant the mechanism

> If the former, named parameters are just a clearer way of calling
> functions that take a lot of parameters or a lot of potentially
> confusing parameters.  If the latter, D currently allows you to do
> something like this:
> 
> class A
> {
>    this(int, int, int){}
> }
> 
> void foo(A a...)
> {
>    // a is a reference to a new instance of A
> }
> 
> foo(1, 2, 3); // same as foo(new A(1, 2, 3));
> 
> So my idea is, if struct literals allow for named members, it's not
> much of a step to go from
> 
> foo(SomeStruct{x: 1, y: 2})
> 
> to:
> 
> foo(x: 1, y: 2)
> 

Ah, I understand now what you meant, I had forgotten about that D 
feature that would implicitly call the constructor on a function call.

>> And what do you mean with "The issue with this is that you have to have a
>> different named struct for every function that takes this style of
>> parameters" ?
>> Were you suggesting that functions who want to receive named parameters
>> should declare an arguments struct just for that?
> 
> Yes.  Although without the syntactic sugar, you'd end up having to write i.e.
> 
> foo(FooArgs{x: 1, y: 2})
> bar(BarArgs{z: 3.4, w: "hi"})
> 
> hence having to repeat the name of the function once for the function
> itself and again for the named arguments.  With sugar, the argument
> structure name and braces go away, but it still doesn't solve the
> problem of having to declare an argument structure for every function.
> 

Yeah, which still makes it un-useful in my opinion.

> But, if we were to get named parameters for all functions, then both
> problems are solved: you have named parameters for free functions and
> methods, and you can initialize structs that have constructors or
> static opCalls with named members instead of having to write them in
> order:
> 
> struct S
> {
>     int x, y, z;
>     this(int x, int y, int z) { this.x = x; this.y = y; this.z = z; }
> }
> 
> S(1, 2, 3) and S(x: 1, y: 2, z: 3) are now both legal.

Now this would be a proper design for the named parameters feature. But 
still, to say the truth, it's not something I miss much. I understand 
it's use case, but I've never felt much need for it in any of the 
languages I've programmed.


-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D