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

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.

on that, for what they're worth....
It occurs to me that the whole POINT of overloading operator () using

is to create an object which behaves like a function - kinda like a modern

version of the old-fashioned callback routine you used to get in C.

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

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

have a function (or at least, a function-like-object) whose name starts

upper case letter.
If there is a real need for a CLASS (as opposed to an instance of a class)

callable, then I can't think of any circumstance where simply providing a

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

argue further that static opCall should be a compile error, as it is a
completely pointless thing to do, and yields code which looks ...

Now, I'm arguing in favor of removing a feature, so I don't expect

agree with me. But this forum is for discussion, so let's discuss. I'd be

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

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

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

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

D are very proud of the fact that D has a simple syntax - see the stuff

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

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.

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

Fair point. I concede that. But what about the distinction between:
(a) A a = new A(parameters);
(b) A a = A(parameters);
..?
Regarding shouting: I've thought a bit about this, and after much contemplation,
I've come to the conclusion that such shouting (in this case) is pretty
meaningless.
Consider: Suppose we see this in source code:

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

Fair point. I concede that. But what about the distinction between:
(a) A a = new A(parameters);
(b) A a = A(parameters);
..?
Regarding shouting: I've thought a bit about this, and after much contemplation,
I've come to the conclusion that such shouting (in this case) is pretty
meaningless.
Consider: Suppose we see this in source code:Regarding shouting: I've thought a
bit about this, and after much contemplation, I've come to the conclusion that
such shouting is pretty meaningless.
Consider: Suppose we see this in source code:

b = a.f();
c = a.g();

functions of typeof(a)) are both called, but we CAN'T see what goes on inside
those functions - not at THIS point in the source code, anyway. Without hunting
down the declarations, we can't know whether f() is a short one-liner and g() is
a thousand lines long, or whether it is the other way round, or neither. Now,
similarly, consider the following two statements:

b = new A();
c = f();

HAPPENING at you, but the truth is, that's not particularly important. After
all, A.this() might be only one line long, or might even be empty. The function
call in the second line might be so complicated that it takes half an hour to
execute. You just can't tell from looking at the code. A constructor, after all,
is just another function.
In fact, the only _real_ thing that "new" tells you is that, at some point,
MEMORY ALLOCATION IS HAPPENING. (A function call only tells you that memory
allocation MIGHT be happening). But is this really a piece of information you
want shouted at you? I would say not, since the mechanism of reserving a slice
of the heap and returning a pointer to it is really not that slow. Actually, in
D, it's very fast. It's the execution of the body of the constructor which takes
the time, and that will be true of _any_ function, not just a constructor.
(Reserving a slice of the stack is unlikely to be much faster if stack-checking
is enabled).
In other words, I don't think that the presence of the keyword "new" in the
statement:

a = new A(parameters);

only useful if it tells you something important, and that's really the point I'm
trying to make. It's not something important, and doesn't need to be shouted.
It's just another function call, so the word just adds unneccessary clutter to
the source code.
Observe that D _encourages_ the use of memory allocation. Its garbage collector
hides the delete process from your source code. (And it's worth pointing out
that, in C++, deletion is much slower than allocation. I don't know if this is
the case in D or not because I don't know how the garbage collector works).
In D, _all_ objects are constructed on the heap. *ALL* of them. Every single
one. I stress this, because it's not true in C++. In C++, the word "new" does
mean something - it tells you that the object is being constructed on the heap
rather than on the stack (and that's ALL it tells you). In D, this is not a
useful thing to know, because it's ALWAYS true. In fact, the only way to stop it
happening is to use a struct rather than a class. (And, interestingly, in C++
the words struct and class are interchangable). In other words, in C++, the word
"new" is important, but in D, the word "class" is important in an analogous way.
My apologies for this tediously long explanation, but I wanted to try to be
clear and avoid misunderstandings. In its present use, the word "new" serves
only to distinguish between a call to this() and a call to static opCall(). I
would prefer that static opCall() be a compile error (because, as I argued in a
previous post, a static functor is just a function - and we already have a
syntax for functions). This would leave the way open for removing the need for
"new" in a call to this().
Arcane Jill

Or use the same instantiation syntax for both templates and classtemplates
and classes, if that's possible; if it is then it seems that new is used to
make class instantiations familiar to outsiders. The template instantiation
syntax is quite neat.

After reading this thread for a while I'd to chime in.
I agree with Arcane Jill point. My motivation is this I'd like D to be a simple
language as possible. Easy to read, easy to write, easy to understand, easy to
maintain, and ofcourse, easy on the compiler. And every unnecessary rule should
be depricated away. Rule such as: new, brace as block of code, class, and
function, semicolon as end of statement. I'll could think of more.
vanh

After reading this thread for a while I'd to chime in.
I agree with Arcane Jill point. My motivation is this I'd like D to be a simple
language as possible. Easy to read, easy to write, easy to understand, easy to
maintain, and ofcourse, easy on the compiler. And every unnecessary rule should
be depricated away. Rule such as: new, brace as block of code, class, and
function, semicolon as end of statement. I'll could think of more.
vanh

After reading this thread for a while I'd to chime in.
I agree with Arcane Jill point. My motivation is this I'd like D to be a simple
language as possible. Easy to read, easy to write, easy to understand, easy to
maintain, and ofcourse, easy on the compiler. And every unnecessary rule should
be depricated away. Rule such as: new, brace as block of code, class, and
function, semicolon as end of statement. I'll could think of more.
vanh

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

Indeed, a major flaw of C is that it makes things _too_ easy to write (i.e.
using a minimum of keystrokes), but when written that way it's dang hard to
read.
I never understood the "fewer keystrokes is better" mentality.

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

1. The reserved word "new" is superfluous. It should be made optional.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In C++, the following two statements are both legal, but do different

(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

is assigned a pointer to it. In case (ii), the object is constructed on

stack, and the variable b is assigned a reference to it. This distinction

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

allocated on the heap, never on the stack, so there is no need for the

keyword to be present to distinguish the two cases. Further, D does not
distinguish between the . operator and the -> operator, It would therefore

both syntactically elegant, and reasonable, to allow the following syntax:
T a = T(parameters); // my suggestion: should be exactly equivalent

a = new T(parameters);
x = a.memberVariable; // member variable access
I suggest, therefore, that the keyword "new" is superfluous, and should be

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

much more pleasing, as there is no needless duplication of the class name.

give a real world example, you only have to compare:
(i) MultiPrecisionDecimal z = new MultiPrecisionDecimal(5.2); //

now
(ii) MultiPrecisionDecimal z(5.2); //

I'm suggesting
Observe how much neater and cleaner version (ii) is. Further, there is (so

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

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

different types of b):
class T
{
this(U b)
{
// do stuff
}
}
To make life easier, it should be a syntax error to use the

operator on an auto class. Of course, it is ALREADY possible to assign

(but not classes) by value. In the case of a struct, I propose that the

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

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

I don't support this syntax form but I would like something like:
new b = T(parameters);
That way there is no repetition which means improved maintance. The
form could be changed, its the repetition reduction that is important.
VB does something like that.
--
-Anderson: http://badmama.com.au/~anderson/

...but I would like something like:
new b = T(parameters);
That way there is no repetition which means improved maintance. The
form could be changed, its the repetition reduction that is important.
VB does something like that.

Interesting syntax. But it LOOKS like an assignment, not a declaration, so it
probably wouldn't work.
Opinion on this thread has not endorsed the second of my suggestions, so I'd be
quite happy to drop it. After all - it's not like I have a PROBLEM - it's just
aesthetics after all. So if:

...but I would like something like:
new b = T(parameters);
That way there is no repetition which means improved maintance. The
form could be changed, its the repetition reduction that is important.
VB does something like that.

Interesting syntax. But it LOOKS like an assignment, not a declaration, so it
probably wouldn't work.
Opinion on this thread has not endorsed the second of my suggestions, so I'd be
quite happy to drop it. After all - it's not like I have a PROBLEM - it's just
aesthetics after all. So if: