Hi guys,
My first suggestions for this forum - three improvements for constructor syntax.



1. The reserved word "new" is superfluous. It should be made optional. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In C++, the following two statements are both legal, but do different things:

(i)     T * a = new T(parameters);  // C++
(ii)    T b = T(parameters);        // C++

In case (i), the object is constructed on the heap (as in D), and the variable a
is assigned a pointer to it. In case (ii), the object is constructed on the
stack, and the variable b is assigned a reference to it. This distinction is
apparent in the way that member variables are later accessed:

(i)     x = a->memberVariable;      // C++
(ii)    y = b.memberVariable;       // C++

Now, NEITHER of these distinctions are relevant in D. Class objects are ALWAYS allocated on the heap, never on the stack, so there is no need for the "new" keyword to be present to distinguish the two cases. Further, D does not distinguish between the . operator and the -> operator, It would therefore be both syntactically elegant, and reasonable, to allow the following syntax:

T a = T(parameters);        // my suggestion: should be exactly equivalent to T
a = new T(parameters);
x = a.memberVariable;       // member variable access

I suggest, therefore, that the keyword "new" is superfluous, and should be made optional - required ONLY if some ambiguity I haven't thought of requires disambiguation.




2. Construction declaration statements ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In C++, the following statement:

T a(parameters);

is equivalent to:

T a = T(parameters);

I suggest that this syntax should also be allowable in D. It is aesthetically much more pleasing, as there is no needless duplication of the class name. To give a real world example, you only have to compare:

(i)     MultiPrecisionDecimal z = new MultiPrecisionDecimal(5.2);       // as
now
(ii)    MultiPrecisionDecimal z(5.2);                                   // what
I'm suggesting

Observe how much neater and cleaner version (ii) is. Further, there is (so far
as I can tell) no possibility of ambiguity here. Syntactic elegance favors
allowing the simpler syntax.




3. Assignment by value
~~~~~~~~~~~~~~~~~~~~~~

Finally, I propose a new operator, := (that's a colon followed by an equals). It should be used like this:

a := b;

Whenever it occurs, it should be rewritten by the compiler as:

a = new T(b);   // where T is the type of A

It could be declared in the obvious way, like this (and multiply overloaded for different types of b):

class T
{
this(U b)
{
// do stuff
}
}

To make life easier, it should be a syntax error to use the assignment-by-value operator on an auto class. Of course, it is ALREADY possible to assign structs (but not classes) by value. In the case of a struct, I propose that the two statements following shall have identical behavior:

a = b;      // as now
a := b;     // rewritten as a = b;

Thus, the existing syntax for both structs and classes is preserved, with its current behaviour, but new, simpler syntaxes also exist to make code smaller, neater, and cleaner.



Well, just my suggestions. Please feel free to consider, accept, or reject. Jill

Currently

        T a = T(arguments);

would call a static opCall defined in the class T.



arcanejill@ramonsky.com wrote:

> 
> Hi guys,
> My first suggestions for this forum - three improvements for constructor
> syntax.
> 
> 
> 
> 1. The reserved word "new" is superfluous. It should be made optional. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> In C++, the following two statements are both legal, but do different things:
> 
> (i)     T * a = new T(parameters);  // C++
> (ii)    T b = T(parameters);        // C++
> 
> In case (i), the object is constructed on the heap (as in D), and the
> variable a is assigned a pointer to it. In case (ii), the object is
> constructed on the stack, and the variable b is assigned a reference to
> it. This distinction is apparent in the way that member variables are
> later accessed:
> 
> (i)     x = a->memberVariable;      // C++
> (ii)    y = b.memberVariable;       // C++
> 
> Now, NEITHER of these distinctions are relevant in D. Class objects are ALWAYS allocated on the heap, never on the stack, so there is no need for the "new" keyword to be present to distinguish the two cases. Further, D does not distinguish between the . operator and the -> operator, It would therefore be both syntactically elegant, and reasonable, to allow the following syntax:
> 
> T a = T(parameters);        // my suggestion: should be exactly equivalent
> to T a = new T(parameters);
> x = a.memberVariable;       // member variable access
> 
> I suggest, therefore, that the keyword "new" is superfluous, and should be made optional - required ONLY if some ambiguity I haven't thought of requires disambiguation.
> 
> 
> 
> 
> 2. Construction declaration statements ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> In C++, the following statement:
> 
> T a(parameters);
> 
> is equivalent to:
> 
> T a = T(parameters);
> 
> I suggest that this syntax should also be allowable in D. It is aesthetically much more pleasing, as there is no needless duplication of the class name. To give a real world example, you only have to compare:
> 
> (i)     MultiPrecisionDecimal z = new MultiPrecisionDecimal(5.2);       //
> as now
> (ii)    MultiPrecisionDecimal z(5.2);                                   //
> what I'm suggesting
> 
> Observe how much neater and cleaner version (ii) is. Further, there is (so
> far as I can tell) no possibility of ambiguity here. Syntactic elegance
> favors allowing the simpler syntax.
> 
> 
> 
> 
> 3. Assignment by value
> ~~~~~~~~~~~~~~~~~~~~~~
> 
> Finally, I propose a new operator, := (that's a colon followed by an equals). It should be used like this:
> 
> a := b;
> 
> Whenever it occurs, it should be rewritten by the compiler as:
> 
> a = new T(b);   // where T is the type of A
> 
> It could be declared in the obvious way, like this (and multiply overloaded for different types of b):
> 
> class T
> {
> this(U b)
> {
> // do stuff
> }
> }
> 
> To make life easier, it should be a syntax error to use the assignment-by-value operator on an auto class. Of course, it is ALREADY possible to assign structs (but not classes) by value. In the case of a struct, I propose that the two statements following shall have identical behavior:
> 
> a = b;      // as now
> a := b;     // rewritten as a = b;
> 
> Thus, the existing syntax for both structs and classes is preserved, with its current behaviour, but new, simpler syntaxes also exist to make code smaller, neater, and cleaner.
> 
> 
> 
> Well, just my suggestions. Please feel free to consider, accept, or reject. Jill

Hear, hear!  (see 'clumsy class instantiation quibble' thread).


<arcanejill@ramonsky.com> wrote in message news:c8f0sa$tqk$1@digitaldaemon.com...
>
> Hi guys,
> My first suggestions for this forum - three improvements for constructor
syntax.
>
>
>
> 1. The reserved word "new" is superfluous. It should be made optional. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> In C++, the following two statements are both legal, but do different
things:
>
> (i)     T * a = new T(parameters);  // C++
> (ii)    T b = T(parameters);        // C++
>
> In case (i), the object is constructed on the heap (as in D), and the
variable a
> is assigned a pointer to it. In case (ii), the object is constructed on
the
> stack, and the variable b is assigned a reference to it. This distinction
is
> apparent in the way that member variables are later accessed:
>
> (i)     x = a->memberVariable;      // C++
> (ii)    y = b.memberVariable;       // C++
>
> Now, NEITHER of these distinctions are relevant in D. Class objects are
ALWAYS
> allocated on the heap, never on the stack, so there is no need for the
"new"
> keyword to be present to distinguish the two cases. Further, D does not distinguish between the . operator and the -> operator, It would therefore
be
> both syntactically elegant, and reasonable, to allow the following syntax:
>
> T a = T(parameters);        // my suggestion: should be exactly equivalent
to T
> a = new T(parameters);
> x = a.memberVariable;       // member variable access
>
> I suggest, therefore, that the keyword "new" is superfluous, and should be
made
> optional - required ONLY if some ambiguity I haven't thought of requires disambiguation.
>
>
>
>
> 2. Construction declaration statements ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> In C++, the following statement:
>
> T a(parameters);
>
> is equivalent to:
>
> T a = T(parameters);
>
> I suggest that this syntax should also be allowable in D. It is
aesthetically
> much more pleasing, as there is no needless duplication of the class name.
To
> give a real world example, you only have to compare:
>
> (i)     MultiPrecisionDecimal z = new MultiPrecisionDecimal(5.2);       //
as
> now
> (ii)    MultiPrecisionDecimal z(5.2);                                   //
what
> I'm suggesting
>
> Observe how much neater and cleaner version (ii) is. Further, there is (so
far
> as I can tell) no possibility of ambiguity here. Syntactic elegance favors allowing the simpler syntax.
>
>
>
>
> 3. Assignment by value
> ~~~~~~~~~~~~~~~~~~~~~~
>
> Finally, I propose a new operator, := (that's a colon followed by an
equals). It
> should be used like this:
>
> a := b;
>
> Whenever it occurs, it should be rewritten by the compiler as:
>
> a = new T(b);   // where T is the type of A
>
> It could be declared in the obvious way, like this (and multiply
overloaded for
> different types of b):
>
> class T
> {
> this(U b)
> {
> // do stuff
> }
> }
>
> To make life easier, it should be a syntax error to use the
assignment-by-value
> operator on an auto class. Of course, it is ALREADY possible to assign
structs
> (but not classes) by value. In the case of a struct, I propose that the
two
> statements following shall have identical behavior:
>
> a = b;      // as now
> a := b;     // rewritten as a = b;
>
> Thus, the existing syntax for both structs and classes is preserved, with
its
> current behaviour, but new, simpler syntaxes also exist to make code
smaller,
> neater, and cleaner.
>
>
>
> Well, just my suggestions. Please feel free to consider, accept, or
reject.
> Jill
>
>

In article <c8f2rl$11af$1@digitaldaemon.com>, Norbert Nemec says...
>
>Currently
>
>        T a = T(arguments);
>
>would call a static opCall defined in the class T.


Yes, it would. That's something I hadn't thought of. Well, here are my thoughts on that, for what they're worth....

It occurs to me that the whole POINT of overloading operator () using opCall() is to create an object which behaves like a function - kinda like a modern day version of the old-fashioned callback routine you used to get in C. There's even a word for them - "functors" - and they are very useful.

However, a STATIC functor? Surely a static functor is just a FUNCTION?

To put it another way, instead of declaring:

       class A
       {
           int opCall(int x, int y)
           {
                // function body
           }
       }

you could just as easily do this:

       int A(int x, int y)
       {
           // function body
       }

which would achieve exactly the same effect. The static functor version does have the ability to access static members of A, which the function version can't, but frankly there are other ways of achieving this effect.

Moreover, the static functor version violates the D style guide in that you now have a function (or at least, a function-like-object) whose name starts with an upper case letter.

If there is a real need for a CLASS (as opposed to an instance of a class) to be callable, then I can't think of any circumstance where simply providing a named member function won't do. That is, instead of calling:

       A(parameters);

we would have to call:

       A.namedFunction(parameters);

So - I can see NO NEED for static functors, and I humbly suggest that the syntax:

       A a = A(parameters)

SHOULD call a constructor, and should NOT call static opCall(). In fact, I would argue further that static opCall should be a compile error, as it is a completely pointless thing to do, and yields code which looks ... unintuitive.

Now, I'm arguing in favor of removing  a feature, so I don't expect everyone to agree with me. But this forum is for discussion, so let's discuss. I'd be really interested to know what others think about this.

<arcanejill@ramonsky.com> wrote in message news:c8fk7j$1s6d$1@digitaldaemon.com...
> In article <c8f2rl$11af$1@digitaldaemon.com>, Norbert Nemec says...
> >
> >Currently
> >
> >        T a = T(arguments);
> >
> >would call a static opCall defined in the class T.
>
>
> Yes, it would. That's something I hadn't thought of. Well, here are my
thoughts
> on that, for what they're worth....
>
> It occurs to me that the whole POINT of overloading operator () using
opCall()
> is to create an object which behaves like a function - kinda like a modern
day
> version of the old-fashioned callback routine you used to get in C.
There's even
> a word for them - "functors" - and they are very useful.
>
> However, a STATIC functor? Surely a static functor is just a FUNCTION?
>
> To put it another way, instead of declaring:
>
>        class A
>        {
>            int opCall(int x, int y)
>            {
>                 // function body
>            }
>        }
>
> you could just as easily do this:
>
>        int A(int x, int y)
>        {
>            // function body
>        }
>
> which would achieve exactly the same effect. The static functor version
does
> have the ability to access static members of A, which the function version can't, but frankly there are other ways of achieving this effect.
>
> Moreover, the static functor version violates the D style guide in that
you now
> have a function (or at least, a function-like-object) whose name starts
with an
> upper case letter.
>
> If there is a real need for a CLASS (as opposed to an instance of a class)
to be
> callable, then I can't think of any circumstance where simply providing a
named
> member function won't do. That is, instead of calling:
>
>        A(parameters);
>
> we would have to call:
>
>        A.namedFunction(parameters);
>
> So - I can see NO NEED for static functors, and I humbly suggest that the syntax:
>
>        A a = A(parameters)
>
> SHOULD call a constructor, and should NOT call static opCall(). In fact, I
would
> argue further that static opCall should be a compile error, as it is a completely pointless thing to do, and yields code which looks ...
unintuitive.
>
> Now, I'm arguing in favor of removing  a feature, so I don't expect
everyone to
> agree with me. But this forum is for discussion, so let's discuss. I'd be
really
> interested to know what others think about this.
>


But static opCall enables you to do exactly what you want!

class A
{
    this(int x){...}
    static A opCall(int x)
    {
        return new A(x);
    }
}

and you can create class objects the in a c++ syntax
A a = A(5);

>But static opCall enables you to do exactly what you want!
>
>class A
>{
>    this(int x){...}
>    static A opCall(int x)
>    {
>        return new A(x);
>    }
>}
>
>and you can create class objects the in a c++ syntax
>A a = A(5);
>
>
>

I had thought of that, but in fact that isn't what I'm suggesting. I don't merely want to be able to create classes which callers can call without "new". I want to be able to construct ANY class without using "new". For example:

OutBuffer a = OutBuffer();

or, better still,

Outbuffer a();

To implement "don't need new" in some classes but not in others would be silly. It would lead to less clarity, not more.

Please understand - this is purely an AESTHETIC consideration. There is no deficiency in the language which needs a workaround. But ... the guys who wrote D are very proud of the fact that D has a simple syntax - see the stuff about complex numbers, for example. If they can implement a simple syntax for something which is so common a task as constructing a class, then, why wouldn't they? Unless it's a hard problem - but I suspect it isn't.

Arcane Jill

"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:c8g72s$2pko$1@digitaldaemon.com...
>
> >But static opCall enables you to do exactly what you want!
> >
> >class A
> >{
> >    this(int x){...}
> >    static A opCall(int x)
> >    {
> >        return new A(x);
> >    }
> >}
> >
> >and you can create class objects the in a c++ syntax
> >A a = A(5);
> >
> >
> >
>
> I had thought of that, but in fact that isn't what I'm suggesting. I don't merely want to be able to create classes which callers can call without
"new". I
> want to be able to construct ANY class without using "new". For example:
>
> OutBuffer a = OutBuffer();
>
> or, better still,
>
> Outbuffer a();
>
> To implement "don't need new" in some classes but not in others would be
silly.
> It would lead to less clarity, not more.
>
> Please understand - this is purely an AESTHETIC consideration. There is no deficiency in the language which needs a workaround. But ... the guys who
wrote
> D are very proud of the fact that D has a simple syntax - see the stuff
about
> complex numbers, for example. If they can implement a simple syntax for something which is so common a task as constructing a class, then, why
wouldn't
> they? Unless it's a hard problem - but I suspect it isn't.
>

I think the way it is now is much clearer and it is very clear from the code
that
a "new" object is being instantiated. And in my opinion this synatx is very
simple
and those three letters "new" aren't that hard to type.


> Arcane Jill
>
>

In article <c8g72s$2pko$1@digitaldaemon.com>, Arcane Jill says...
>
>
>want to be able to construct ANY class without using "new". For example:
>
>OutBuffer a = OutBuffer();
>
>or, better still,
>
>Outbuffer a();

but, isn't that an abstract function declaration
that returns an object of type Outbuffer?

Ant

In article <c8g87d$2rht$1@digitaldaemon.com>, Ivan Senji says...
>
>and those three letters "new" aren't that hard to type.
>

(I've said this before, I promisse it's the last time.)

It isn't the how hard is to type that matters
it's how easy is to read.

Ant

"Ant" <Ant_member@pathlink.com> wrote in message news:c8g9om$2toq$1@digitaldaemon.com...
> In article <c8g87d$2rht$1@digitaldaemon.com>, Ivan Senji says...
> >
> >and those three letters "new" aren't that hard to type.
> >
>
> (I've said this before, I promisse it's the last time.)
>
> It isn't the how hard is to type that matters
> it's how easy is to read.

What i wanted to write was:
A a = new A();
is much easier to read than
A a();

The first one just shouts "instantiating object here"
and the second one doesn't


> Ant
>
>