Georg Wrede wrote:
> /At least 1.xx/ should do this.

That's why the default download is for an older version.

Jarrett Billingsley wrote:
> q{ is treated more or less as an atomic character.  Put a space
> between them and bam, you have a struct literal.

They made exactly that mistake with C++'s template syntax.  It is one of the reasons that D's template syntax is better.

It's an idea that sounds good when you are looking at it from an abstract, "yeah we could parse that" direction, but it makes for unreadable (and unwritable) code with strange syntax errors that are hard to find.

On Sat, Sep 6, 2008 at 8:38 AM, Russell Lewis <webmaster@villagersonline.com> wrote:
> Jarrett Billingsley wrote:
>>
>> q{ is treated more or less as an atomic character.  Put a space between them and bam, you have a struct literal.
>
> They made exactly that mistake with C++'s template syntax.  It is one of the reasons that D's template syntax is better.
>
> It's an idea that sounds good when you are looking at it from an abstract, "yeah we could parse that" direction, but it makes for unreadable (and unwritable) code with strange syntax errors that are hard to find.
>

I'll agree with that and reiterate that if we could have named parameters I could care less about having better struct literals.

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.
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?

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

On Mon, Sep 8, 2008 at 9:39 AM, Bruno Medeiros <brunodomedeiros+spam@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?

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)

> 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.

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.

On Mon, Sep 8, 2008 at 9:39 AM, Bruno Medeiros <brunodomedeiros+spam@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?

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)

> 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.

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.

Jarrett Billingsley wrote:
> On Mon, Sep 8, 2008 at 9:39 AM, Bruno Medeiros
> <brunodomedeiros+spam@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

Bruno Medeiros:
> 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.

If you use an IDE, it tells shows you the signature of the function/method, so such feature is less useful. But if you don't use an IDE, or you are using a dynamic language (where for the IDE is less easy to give help), they become quite useful, especially when you have several arguments, and several of them have a default value. So it's a form of documentation of the code, helps avoid some bugs, reduced the need to remember the exact signature if you don't have an IDE, etc. As most things if you overdo it, it may give you problems...

Note that for delegates/closures named arguments may give some problems, because you don't know at compile time what is the order of the arguments. To solve this problem in ShedSkin I have added an extra hidden uint or ulong argument to those closures, used as a bitmask of 32 or 64 bits, to tell the closure what are the arguments actually passed... :-) If you want more details I can explain. If there are more than 64 arguments you can add a second uint or ulong, etc.

Bye,
bearophile