grauzone Wrote:

> Do people really like such code and not cringe over how unclean and inelegant it is? Maybe it's just me...

it's not just you - i agree totally. If i wanted inelegant hacks, i'd be using C++ plus I always like a standard way of doing simple things.

On Sun, 26 Apr 2009 04:17:04 -0400, Daniel Keep <daniel.keep.lists@gmail.com> wrote:

>
>
> Penguin wrote:
>> What do you think about:
>>
>> class Foo {
>>
>>    int a;
>>    float b;
>>
>>    this( member a, member b ) {
>>
>>    }
>>
>> }
>>
>> instead of:
>>
>> class Foo {
>>
>>    int a;
>>    float b;
>>
>>    this( int a, float b ) {
>>       this.a = a;
>>       this.b = b;
>>    }
>>
>> }
>
> I don't know that saving a few (very simple) lines of code is worth
> adding a new keyword and magic behaviour to ctor arguments.
>
> If you really wanted to just do that, you could probably write a mixin
> to take care of it.

There are three benefits I see to the proposal:

1. It saves typing.  This is not usually a big deal, except that this sort of constructor is EXTREMELY common with container objects.
2. It saves having to specify the type.  We get the same savings from "auto," it should be similar here.  In fact, you could probably change the keyword "member" to "auto".
3. It's a little more self documenting.  You know when you see the function signature, that what you pass in will at least start being the initial value of the named member.

The drawback of course is the keyword.  the magic behavior is not a drawback IMO (in fact, it is the point).

If you used auto as the keyword, you don't add a keyword.

I'd vote for it.  Of course, I'd rather have inherited constructors first ;)

-Steve

Steven Schveighoffer wrote:
> ...
> 
> There are three benefits I see to the proposal:
> 
> 1. It saves typing.  This is not usually a big deal, except that this sort of constructor is EXTREMELY common with container objects.

Fair enough.

> 2. It saves having to specify the type.  We get the same savings from "auto," it should be similar here.  In fact, you could probably change the keyword "member" to "auto".

True, but...

> 3. It's a little more self documenting.  You know when you see the function signature, that what you pass in will at least start being the initial value of the named member.

class Act
{
    this(auto a, auto b) {}

    // a million billion lines of code

    private { int a; Wombat b; }

    // another million billion lines of code.  And a pony.
}

Working out the type of a or b will be a major pain in the arse.

It's less documenting in the sense that you'll see the ctor and have no idea what you should be passing to it.

> The drawback of course is the keyword.  the magic behavior is not a drawback IMO (in fact, it is the point).

The magic-ness is a Bad Thing™.  You're obfuscating the interface.  This
isn't like auto in code since there you care about how you use the
thing, not the exact type.

But here, you have users who NEED to know what the type is.

> If you used auto as the keyword, you don't add a keyword.
> 
> I'd vote for it.  Of course, I'd rather have inherited constructors first ;)
> 
> -Steve

For me, the real nail-in-the-coffin is that you can do this with mixins.
 Yes, grauzone, they're not pretty.  But they work and they don't
require language changes.

Besides, it gives us fuel to bug Walter about implementing macros. :D

  -- Daniel

On Mon, 27 Apr 2009 08:51:03 -0400, Daniel Keep <daniel.keep.lists@gmail.com> wrote:

>
>
> Steven Schveighoffer wrote:
>> ...
>>
>> There are three benefits I see to the proposal:
>>
>> 1. It saves typing.  This is not usually a big deal, except that this
>> sort of constructor is EXTREMELY common with container objects.
>
> Fair enough.
>
>> 2. It saves having to specify the type.  We get the same savings from
>> "auto," it should be similar here.  In fact, you could probably change
>> the keyword "member" to "auto".
>
> True, but...
>
>> 3. It's a little more self documenting.  You know when you see the
>> function signature, that what you pass in will at least start being the
>> initial value of the named member.
>
> class Act
> {
>     this(auto a, auto b) {}
>
>     // a million billion lines of code
>
>     private { int a; Wombat b; }
>
>     // another million billion lines of code.  And a pony.
> }
>
> Working out the type of a or b will be a major pain in the arse.

Just like:

void foo()
{
  int a, b;
  // a million billion lines of code
  auto c = a; // what type is a?
}

>> If you used auto as the keyword, you don't add a keyword.
>>
>> I'd vote for it.  Of course, I'd rather have inherited constructors
>> first ;)
>>
>> -Steve
>
> For me, the real nail-in-the-coffin is that you can do this with mixins.
>  Yes, grauzone, they're not pretty.  But they work and they don't
> require language changes.

Yes, the mixin Nick provided is handy.  I guess you are right.

-Steve