member arguments in D?

[Daniel Keep]

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