Feature request - simpler constructors

[kris]

Janice Caron wrote:
> On 9/21/07, Walter Bright <newshound1 at digitalmars.com> wrote:
>> Janice Caron wrote:
>>> Please could we let
>> I think it's a good idea, but I think using the function signature for
>> it probably is not the best idea (as the function signature is for the
>> interface, not the internals).
> 
> Ah, well since that initial idea, lots of people have come up with
> different alternatives, and the one suggested by Regan Heath is really
> nice:
> 
> class Point {
>   int x;
>   int y;
>   int foo;  //not implicitly assigned any value
> 
>   this(int x, int y, int bar):(x,y)  //bar is not assigned to anything
>   {
>     //super constructor calls go here
>     //members are assigned here (_after_ calling super)
>     //first line of user code goes here
>     if (x > 5) {}  //refers to member 'x' not parameter 'x'
>   }
> }
> 
> It's sort of similar to C++'s approach, but less typing and you don't
> have to pick two different names for each variable, and if you wrote
> the colon bit on the next line, it wouldn't be in the function
> signature. (And if you didn't like the overuse of colon, you could
> always use a keyword like you do for in, out and body).
> 
> What I like about it is that you can do this:
> 
>   this(int x, int y, int bar):(y,x)  //first assign y, then assign x
> 
> in case there are side-effects to assignment order. Even better would
> be to allow
> 
>   this(int x, int y, int bar):(...)
> 
> to be equivalent to
> 
>   this(int x, int y, int bar):(x,y,bar)
> 
> as between them, that set of possibilities seems to cover every need
> suggested so far, including your need of not using the function
> signature.


Wow

All of that extra learning, indirection, and potential for confusion 
just to avoid typing a relatively minuscule number of characters within 
the ctor of a class:

# this.x = x, this.y = y;

I'm just knocked out. Really.

Here's a thought for everyone to consider. Please take a look at a large 
and /practical/ body of code, written in D, by capable programmers, and 
actually count the number of times this would even be applied? Now, take 
that number and calculate a percentage against the size of the code body.

There's plenty of code in dsource to validate this notion against, 
rather than speculating on a fictional basis.

FWIW: I'm quite familiar with at least two rather large bodies of code 
there, and I can take a quick guess that neither body would apply 
something like this even once, because there's simply no need for it. 
Naturally, that doesn't cover every scenario or even a wide set of 
tastes. However, it does indicate rather well that the notably few 
"speshul" cases where this /might/ ever get used would likely cause 
confusion to the reader or maintainer: *because it's not used often 
enough to remember*

That spells "Feature Creep to The Max"

Just wow