www.digitalmars.com         C & C++   DMDScript  

D - auto construction syntax simplification

reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
Walter

A while back I mentioned that it would be nice to allow auto instances to be
constructed without the (syntactically consistent but semantically
misleading) new syntax. In other words

            auto ExeModule xmod =   new ExeModule(moduleName);

could be written as the more accurate

            ExeModule xmod(moduleName);

If memory serves, you liked this, but it's not yet implemented. Are there
plans to do this? Is it as simple as it seems to be to implement?

Cheers

The Easter Bunny
Dec 31 2003
next sibling parent reply Antti =?iso-8859-1?Q?Syk=E4ri?= <jsykari gamma.hut.fi> writes:
In article <bt0gqk$ion$1 digitaldaemon.com>, Matthew wrote:

 Walter
 
 A while back I mentioned that it would be nice to allow auto instances to be
 constructed without the (syntactically consistent but semantically
 misleading) new syntax. In other words
 
             auto ExeModule xmod =   new ExeModule(moduleName);
 
 could be written as the more accurate
 
             ExeModule xmod(moduleName);

 If memory serves, you liked this, but it's not yet implemented. Are there
 plans to do this? Is it as simple as it seems to be to implement?


It would indeed be nice if the tedious repetition of ExeModule above
wouldn't be necessary. However, I believe that this form of
initialization caused so much parsing grief in C++ that is was removed
in D? "ExeModule xmod(moduleName);" could either be a function
declaration or a variable initializer. The parser must guess whether
moduleName above is a type or a variable name, and worse, the human
reader must, too. It is easier because moduleName is likely to denote a
variable because it's not capitalized. But what if there are no
arguments at all?

There is of course the option of banning function declarations
altogether inside function bodies. And if auto declarations are allowed
inside class bodies and globally (which makes complete sense in light of
C++ RAII usage), then another can of worms is opened.

Or then another syntax; how about:

ExeModule xmod = moduleName; // Do as the ints do

or

ExeModule xmod = moduleName, anotherArgument; // Multiple arguments

or

ExeModule xmod = (moduleName, anotherArgument); // Easier for the eye?

or

ExeModule xmod.this(moduleName, anotherArgument);

-Antti
Jan 01 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
 In article <bt0gqk$ion$1 digitaldaemon.com>, Matthew wrote:

 Walter

 A while back I mentioned that it would be nice to allow auto instances




to be

 constructed without the (syntactically consistent but semantically
 misleading) new syntax. In other words

             auto ExeModule xmod =   new ExeModule(moduleName);

 could be written as the more accurate

             ExeModule xmod(moduleName);

 If memory serves, you liked this, but it's not yet implemented. Are




there

 plans to do this? Is it as simple as it seems to be to implement?


 It would indeed be nice if the tedious repetition of ExeModule above
 wouldn't be necessary. However, I believe that this form of
 initialization caused so much parsing grief in C++ that is was removed
 in D? "ExeModule xmod(moduleName);" could either be a function
 declaration or a variable initializer. The parser must guess whether
 moduleName above is a type or a variable name, and worse, the human
 reader must, too. It is easier because moduleName is likely to denote a
 variable because it's not capitalized. But what if there are no
 arguments at all?


You're almost right. It's only a problem when there are no arguments.


 There is of course the option of banning function declarations
 altogether inside function bodies. And if auto declarations are allowed
 inside class bodies and globally (which makes complete sense in light of
 C++ RAII usage), then another can of worms is opened.

 Or then another syntax; how about:

 ExeModule xmod = moduleName; // Do as the ints do

 or

 ExeModule xmod = moduleName, anotherArgument; // Multiple arguments

 or

 ExeModule xmod = (moduleName, anotherArgument); // Easier for the eye?

 or

 ExeModule xmod.this(moduleName, anotherArgument);

 -Antti


Nope. It needs to be

             ExeModule xmod(moduleName);

Virtually no-one uses local function declarations in C++, and I don't
foresee any issues in our outlawing them in D. If necessary, we could have a
"function" keyword to force a declaration, as in


             function ExeModule xmod(); // Now is a function called xmod
that returns ExeModule

but I really don't think this is necessary.

Happy New Year


-- 
Matthew Wilson

STLSoft moderator (http://www.stlsoft.org)
Contributing editor, C/C++ Users Journal
(www.synesis.com.au/articles.html#columns)

"I can't sleep nights till I found out who hurled what ball through what
apparatus" -- Dr Niles Crane

----------------------------------------------------------------------------
---
Jan 01 2004
parent reply Ilya Minkov <minkov cs.tum.edu> writes:
Matthew wrote:

 Virtually no-one uses local function declarations in C++, and I don't
 foresee any issues in our outlawing them in D.


STOP. inner functions are one of the most useful features in D, which 
partly compenastes for the lack of preprocessor!

-eye
Jan 02 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
Do you have some compelling examples?

I'm not sure we're talking about the same thing here

"Ilya Minkov" <minkov cs.tum.edu> wrote in message
news:bt3qnp$2d45$1 digitaldaemon.com...

 Matthew wrote:

 Virtually no-one uses local function declarations in C++, and I don't
 foresee any issues in our outlawing them in D.


 STOP. inner functions are one of the most useful features in D, which
 partly compenastes for the lack of preprocessor!

 -eye
Jan 02 2004
parent reply Ilya Minkov <minkov cs.tum.edu> writes:
Are we talking of the possibility to define a function within a 
function? This inner function would be able to acess the locals of the 
function it is defined in, which is very useful. I think examples were 
in C or C++ to D transition in the manual. These are things where you 
would #define a function-like macro on the beginning of function in C++, 
and #undef it at the end. Like, you see repetitious code in a function, 
but it acesses local variables, so you factor it out, either by writing 
a macro or by creating a struct to hold locals. With D, there is this 
elegant solution with inner functions. I can dig out some real-world 
examples if you like.

The thing is, we also need a possibility to make forward declarations 
for such functions, because in local scope, as opposed to global scope, 
forward declarations are not automatic. You cannot make alternating 
recursion without forward declarations.

-eye

Matthew wrote:

 Do you have some compelling examples?
 
 I'm not sure we're talking about the same thing here
Jan 04 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
So we'd need a function keyword, then.

"Ilya Minkov" <minkov cs.tum.edu> wrote in message
news:bta1s8$2f9j$1 digitaldaemon.com...

 Are we talking of the possibility to define a function within a
 function? This inner function would be able to acess the locals of the
 function it is defined in, which is very useful. I think examples were
 in C or C++ to D transition in the manual. These are things where you
 would #define a function-like macro on the beginning of function in C++,
 and #undef it at the end. Like, you see repetitious code in a function,
 but it acesses local variables, so you factor it out, either by writing
 a macro or by creating a struct to hold locals. With D, there is this
 elegant solution with inner functions. I can dig out some real-world
 examples if you like.

 The thing is, we also need a possibility to make forward declarations
 for such functions, because in local scope, as opposed to global scope,
 forward declarations are not automatic. You cannot make alternating
 recursion without forward declarations.

 -eye

 Matthew wrote:

 Do you have some compelling examples?

 I'm not sure we're talking about the same thing here
Jan 04 2004
parent Hauke Duden <H.NS.Duden gmx.net> writes:
Matthew wrote:

 So we'd need a function keyword, then.


Why not create auto objects like this:

auto Foo bar("xy",z);

instead of auto Foo bar=new Foo("xy",z);

The extra auto shouldn't be too much to type. And the syntax seems to be 
unambiguous to me, since functions cannot return auto objects (IIRC).

Hauke
Jan 04 2004
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:bt0gqk$ion$1 digitaldaemon.com...

 Walter

 A while back I mentioned that it would be nice to allow auto instances to


be

 constructed without the (syntactically consistent but semantically
 misleading) new syntax. In other words

             auto ExeModule xmod =   new ExeModule(moduleName);

 could be written as the more accurate

             ExeModule xmod(moduleName);

 If memory serves, you liked this, but it's not yet implemented. Are there
 plans to do this? Is it as simple as it seems to be to implement?


As the other respondents pointed out, there are many parsing issues to be
worked out to make this work. I think we'll leave it as is for the time
being.
Jan 13 2004
parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
Walter wrote:

 "Matthew" <matthew.hat stlsoft.dot.org> wrote in message
 news:bt0gqk$ion$1 digitaldaemon.com...
 

Walter

A while back I mentioned that it would be nice to allow auto instances to


 
 be
 

constructed without the (syntactically consistent but semantically
misleading) new syntax. In other words

            auto ExeModule xmod =   new ExeModule(moduleName);

could be written as the more accurate

            ExeModule xmod(moduleName);

If memory serves, you liked this, but it's not yet implemented. Are there
plans to do this? Is it as simple as it seems to be to implement?


 
 
 As the other respondents pointed out, there are many parsing issues to be
 worked out to make this work. I think we'll leave it as is for the time
 being.


What about this one?

auto ExeModule xmod(moduleName);



Hauke
Jan 14 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Hauke Duden" <H.NS.Duden gmx.net> wrote in message
news:bu357d$b60$1 digitaldaemon.com...

 Walter wrote:

 "Matthew" <matthew.hat stlsoft.dot.org> wrote in message
 news:bt0gqk$ion$1 digitaldaemon.com...


Walter

A while back I mentioned that it would be nice to allow auto instances






to

 be


constructed without the (syntactically consistent but semantically
misleading) new syntax. In other words

            auto ExeModule xmod =   new ExeModule(moduleName);

could be written as the more accurate

            ExeModule xmod(moduleName);

If memory serves, you liked this, but it's not yet implemented. Are






there

plans to do this? Is it as simple as it seems to be to implement?



 As the other respondents pointed out, there are many parsing issues to




be

 worked out to make this work. I think we'll leave it as is for the time
 being.


 What about this one?

 auto ExeModule xmod(moduleName);


That's good. Can we have that Walter?
Jan 14 2004
parent reply "C" <dont respond.com> writes:
Honestly I kind of like the current syntax.  I think one of the gotchas
moving from C++ is forgetting to new everything , if we require the same
syntax it will drive home that everything must be new'ed.

C


"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:bu35b2$bii$1 digitaldaemon.com...

 "Hauke Duden" <H.NS.Duden gmx.net> wrote in message
 news:bu357d$b60$1 digitaldaemon.com...

 Walter wrote:

 "Matthew" <matthew.hat stlsoft.dot.org> wrote in message
 news:bt0gqk$ion$1 digitaldaemon.com...


Walter

A while back I mentioned that it would be nice to allow auto instances






 to

 be


constructed without the (syntactically consistent but semantically
misleading) new syntax. In other words

            auto ExeModule xmod =   new ExeModule(moduleName);

could be written as the more accurate

            ExeModule xmod(moduleName);

If memory serves, you liked this, but it's not yet implemented. Are






 there

plans to do this? Is it as simple as it seems to be to implement?



 As the other respondents pointed out, there are many parsing issues to




 be

 worked out to make this work. I think we'll leave it as is for the






time

 being.


 What about this one?

 auto ExeModule xmod(moduleName);


 That's good. Can we have that Walter?
Jan 14 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
But auto instances do not exist on the heap and, for me at least, new says
"create one of these on the heap".

I grant you, or anyone else, that new actually has two functions, and my
focus on the heap side (as opposed to the construction side) is undoubtedly
from my C++ thinking


"C" <dont respond.com> wrote in message
news:bu4fqf$2guo$1 digitaldaemon.com...

 Honestly I kind of like the current syntax.  I think one of the gotchas
 moving from C++ is forgetting to new everything , if we require the same
 syntax it will drive home that everything must be new'ed.

 C


 "Matthew" <matthew.hat stlsoft.dot.org> wrote in message
 news:bu35b2$bii$1 digitaldaemon.com...

 "Hauke Duden" <H.NS.Duden gmx.net> wrote in message
 news:bu357d$b60$1 digitaldaemon.com...

 Walter wrote:

 "Matthew" <matthew.hat stlsoft.dot.org> wrote in message
 news:bt0gqk$ion$1 digitaldaemon.com...


Walter

A while back I mentioned that it would be nice to allow auto










instances

 to

 be


constructed without the (syntactically consistent but semantically
misleading) new syntax. In other words

            auto ExeModule xmod =   new ExeModule(moduleName);

could be written as the more accurate

            ExeModule xmod(moduleName);

If memory serves, you liked this, but it's not yet implemented. Are






 there

plans to do this? Is it as simple as it seems to be to implement?



 As the other respondents pointed out, there are many parsing issues








to

 be

 worked out to make this work. I think we'll leave it as is for the






 time

 being.


 What about this one?

 auto ExeModule xmod(moduleName);


 That's good. Can we have that Walter?
Jan 14 2004
next sibling parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
Matthew wrote:


But auto instances do not exist on the heap and, for me at least, new says
"create one of these on the heap".

I grant you, or anyone else, that new actually has two functions, and my
focus on the heap side (as opposed to the construction side) is undoubtedly
from my C++ thinking

  


What about:

ExeModule xmod = auto ExeModule(moduleName);

then?



"C" <dont respond.com> wrote in message
news:bu4fqf$2guo$1 digitaldaemon.com...
  


Honestly I kind of like the current syntax.  I think one of the gotchas
moving from C++ is forgetting to new everything , if we require the same
syntax it will drive home that everything must be new'ed.

C
Jan 14 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
"J Anderson" <REMOVEanderson badmama.com.au> wrote in message
news:bu51da$ah3$1 digitaldaemon.com...



"C" <dont respond.com> wrote in message
news:bu4fqf$2guo$1 digitaldaemon.com...



Honestly I kind of like the current syntax.  I think one of the gotchas
moving from C++ is forgetting to new everything , if we require the same
syntax it will drive home that everything must be new'ed.

C




 Matthew wrote:


But auto instances do not exist on the heap and, for me at least, new




says

"create one of these on the heap".

I grant you, or anyone else, that new actually has two functions, and my
focus on the heap side (as opposed to the construction side) is




undoubtedly

from my C++ thinking


 What about:

 ExeModule xmod = auto ExeModule(moduleName);

 then?


That's almost as verbose as it already is

    auto ExeModule xmod = new ExeModule(moduleName);

I really think

    auto ExeModule xmod(moduleName);

is the best compromise. It's not ambiguous wrt local function declarations,
and it's pretty clear what's going on.

Walter?
Jan 14 2004
next sibling parent Alix Pexton <Alix thedjournal.com> writes:
I admit that I haven't really thought about it, but the way D reuses the 
'this' keyword gave me an idea...

ExeModule xmod = auto(moduleName);

how does that do?
I don't realy like it my self, but I think the statement *needs* to have 
an equals in it, so that non D-adepts can look at it and know it is 
declaring a variable.

If it were unambiguous, I suspect that the following would also be 
possible for non-auto instances...

SomeClass obj = new(parameters);

which has the same non-replication.

Like I said I don't actually like this form myself, but I felt I had to 
share.

Alix...


Matthew wrote:


What about:

ExeModule xmod = auto ExeModule(moduleName);

then?
    


That's almost as verbose as it already is

    auto ExeModule xmod = new ExeModule(moduleName);

I really think

    auto ExeModule xmod(moduleName);

is the best compromise. It's not ambiguous wrt local function declarations,
and it's pretty clear what's going on.

Walter?





  



-- 
            Alix Pexton
Webmaster - http://www.theDjournal.com

            Alix theDjournal.com
Jan 15 2004
prev sibling parent reply davepermen <davepermen_member pathlink.com> writes:
auto ExeModule xmod(moduleName);




I'd prefer

ExeModule xmod = auto(moduleName);

somehow.. i don't like the constructor parameters bound to the object.. looks
like an opCall for me, dunno how nice to parse..

or

ExeModule(moduleName) xmod;

that would be best possibly. not even an auto needed.

why is that best? because constructor gets called the very same way, just not on
a new-ed object ( = new ExeModule(moduleName); ), but directly on the stack
(just as int x, the int will be on the stack)..

i think the last proposial of me is the most logical one. more logical than the
c++ way at least.

its the same as

int[] x;

instead of

int x[];

and

Type(params) name; would be unambiguous to parse. and short. and understandable.
doesn't even require the auto keyword then anymore. wich is a good thing imho..

oh, and.. if the constructor has no parameters, you still have to call it with
Type() name;

this could even be standard. instanciate an object of some type has to be done
with Type(...). if you want it on the gc-heap, you new it. else, you just use it
(and then, it will behave stackbased..)

Type(); unnamed object on the stack

new Type(); unnamed object on the heap

Type; unnamed reference

Type name; named reference

Type name = new Type(); named reference to an unnamed object on the heap

Type name = Type(); named reference to an unnamed object on the stack

Type() name; named object on the stack

new Type() name; named object on the heap :D

hehe, fun:D
Jan 15 2004
next sibling parent Georg Wrede <Georg_member pathlink.com> writes:
I like this!!

This way the language makes it very clear that we are doing
two different kinds of things. Even newbies would spot this
easily. 

"Simplicity, clarity, generality." Kernighan & Pike


In article <bu73om$o91$1 digitaldaemon.com>, davepermen says...
..

i think the last proposial of me is the most logical one. more
logical than the c++ way at least.

its the same as

int[] x;


..

and

Type(params) name; would be unambiguous to parse. and short. and
understandable. Doesn't even require the auto keyword then anymore.
wich is a good thing imho..

oh, and.. if the constructor has no parameters, you still have to
call it with Type() name;

this could even be standard. instanciate an object of some type has
to be done with Type(...). if you want it on the gc-heap, you new it.
Else, you just use it (and then, it will behave stackbased..)

Type(); unnamed object on the stack
new Type(); unnamed object on the heap
Type; unnamed reference
Type name; named reference
Type name = new Type(); named reference to an unnamed object on the heap
Type name = Type(); named reference to an unnamed object on the stack
Type() name; named object on the stack
new Type() name; named object on the heap :D
Jan 16 2004
prev sibling parent reply Antti =?iso-8859-1?Q?Syk=E4ri?= <jsykari gamma.hut.fi> writes:
In article <bu73om$o91$1 digitaldaemon.com>, davepermen wrote:

auto ExeModule xmod(moduleName);




 
 I'd prefer
 
 ExeModule xmod = auto(moduleName);
 
 somehow.. i don't like the constructor parameters bound to the object.. looks
 like an opCall for me, dunno how nice to parse..
 
 or
 
 ExeModule(moduleName) xmod;


For some reason, this one actually seems an incredibly good. It just
seems as if it's the one syntax everybody's been hunting down all the
time.

It might have small but solvable parsing issues (the part before "xmod"
first looks like a function call) and it just might not be the perfect
one, but I like the terseness and consistency with "new
ExeModule(moduleName)"

Yet I think that the following should mean the same:

ExeModule() xmod; // instantiate ExeModule with no args
ExeModule xmod;   // instantiate ExeModule with no args

You know, "do as the ints do". And if there's no need to sprinkle
superfluous parentheses around, I'd rather not.

-Antti
Jan 18 2004
next sibling parent Antti =?iso-8859-1?Q?Syk=E4ri?= <jsykari gamma.hut.fi> writes:
In article <slrnc0mcde.f82.jsykari pulu.hut.fi>, Antti Sykäri wrote:

 In article <bu73om$o91$1 digitaldaemon.com>, davepermen wrote:

auto ExeModule xmod(moduleName);




 
 I'd prefer
 
 ExeModule xmod = auto(moduleName);
 
 somehow.. i don't like the constructor parameters bound to the object.. looks
 like an opCall for me, dunno how nice to parse..
 
 or
 
 ExeModule(moduleName) xmod;


 
 For some reason, this one actually seems an incredibly good. It just
 seems as if it's the one syntax everybody's been hunting down all the
 time.


*Ahem*  I probably was in an imaginary wonderland where saying

ExeModule xmod;

would indicate declaring a variable of type xmod _and_ instantiating it
using the default constructor. In the D as we know it, it may or may not
instantiate an object of type xmod, depending on its kind (class objects
are not instantiated, struct objects are.) Now it would be silly if a
class object suddenly _would_ be instantiated if it's just marked
"auto". The policy of how to create an object should not be controlled
by whether it's a representative of a "class", or a "struct", or an
"auto class", however obvious it is to the seasoned programmer who knows
how these concepts are implemented (and who never makes mistakes
anyway).

The rules could be simplified to some extent if "ExeModule() xmod" would
instantiate the object it but "ExeModule xmod" wouldn't. But then we are
in the C++ land where "Foo bar();" means a different thing than "Foo
bar;", and confusing the two causes diabolically cryptical parse errors
since the former is a function declaration and the latter is a variable
declaration. In other words: don't go there.

*However* -- I'm not quite out of silly ideas yet -- what if *all*
references were explicitly marked so instead of being implicitly
determined by the "classness" of an object? Let's create a new kind of
derived type, "reference type" -- which acts precisely like class object
types do, namely that objects are treated by reference as opposed to by
value.  This means effectively pointers with implicit address-taking and
dereferencing. Then introduce the rule that all objects, whether they be
struct or class or fundamental type, are by value by default and by
reference only if marked as so.

Since these references are not the same references as C++ has, and
because C++ has an awfully confusing syntax for them, we don't use C++
syntax. Instead let's adopt the syntax "ref Type" (originally from Algol
68). Examples:

class Object
{
    this() { ... }
    this(int x) { ... }
}

struct Struct
{
    this() { ... }
    this(int x) { ... }
}

void main()
{
    int i;        // an int, initialized to 0.
    int j = 5;    // an int, initialized to 5.
    int(5) j;     // the same, using the cool syntax invented by davepermen.

    ref Struct a; // a reference to a Struct, initialized to null.
    ref Struct b = new Struct(5); // reference to a struct, new'ed from the heap
    ref Struct(5) c; // same as above. (maybe?)
    Struct d;     // a Struct, initialized to default value
    Struct(5) e;    // do as the ints do!

    // With objects, everything is the same except they can't be
    // instantiated on the stack.

    ref Object x; // Reference to Object, initialized to null.
    ref Object y = new Object(5); // Do like the structs do. :)
    ref Object(5) z; // likewise
    Object w;     // Illegal! You can only make references of class types
    Object(5) v;  // Illegal as well.

    // Actually, why not the following as well, if need be:
    ref int = new int(5); // do as the structs do! ;)
}

Perhaps "ref" could be similar property like "auto", so that you can
declare "ref class ClassName { ... }" and then they would be all by
reference. OTOH then you wouldn't know whether you're looking at a
reference or a normal variable if you see a declaration somewhere. So
just perhaps.

Now why would this be good?

a) overall simplicity and consistency in the language

which leads to:

b) seamless migration from structs to classes. You can use structs and
pass them around using references, and if you need dynamic behavior you
can change them to classes with no change in semantics at all. And vice
versa! (Ignoring the fact that constructors do not (yet?) properly work
for structs, is that correct)

c) no need to think "should I make this concept a struct or a class" --
just pick one, you can change it later if needed

d) even less need to use pointers (now that structs can be passed by
reference)

and, most importantly,

e) no newbies asking "Why does my program 'MyClass x; x.helloWorld();'
fail"

I don't really know just *how* important (e) would be, but guess it
wouldn't hurt either. Besides everybody is supposed to know Java (tm)
nowadays so I guess everybody knows how to avoid the dreaded
NullPointerException.

Not all roses and sunshine here though. Some bad sides of making
reference types explicit that I can think of are:

a) it's a move that would require significant re-engineering of the
language; For example, do function argument passing modes need to be
rethought?  How?

b) there might be non-obvious semantical gaps in the language after the
change (well, probably more than there are now at least); For example,
how do references to references behave?


risky (as if it mattered before)

...All right, maybe I'll implement it in my OWN language (some day!)

-Antti
Jan 18 2004
prev sibling parent Hauke Duden <H.NS.Duden gmx.net> writes:
Antti Sykäri wrote:

ExeModule(moduleName) xmod;


 
 
 For some reason, this one actually seems an incredibly good. It just
 seems as if it's the one syntax everybody's been hunting down all the
 time.
 
 It might have small but solvable parsing issues (the part before "xmod"
 first looks like a function call) and it just might not be the perfect
 one, but I like the terseness and consistency with "new
 ExeModule(moduleName)"
 
 Yet I think that the following should mean the same:
 
 ExeModule() xmod; // instantiate ExeModule with no args
 ExeModule xmod;   // instantiate ExeModule with no args


That's the problem: the last one is already used to create a reference. 
And I think the one before is too close to the reference thing - there 
should be some more noticeable difference.

However, I agree that having the arguments after the class name does 
seem "right" and is more consistent with the rest of the language (i.e. 
the new syntax).

So, what about

auto ExeModule(moduleName) xmod;

This makes it more obvious that you're dealing with an auto object and 
at the same time it solves the minor parsing issue you mentioned.

Hauke
Jan 19 2004
prev sibling parent "Ben Hinkle" <bhinkle4 juno.com> writes:
auto, as written in the D doc, is independent of where the object is
allocated. In fact I can't find anything in the dmd source that indicates it
is on the stack. I think it would be tricky to allocate on the stack
currently because the compiler would have to know from a statement like
 auto Class x = new Subclass();
to ignore the size of Class and use the size of Subclass. Also what about
 auto Class x = something_that_returns_an_object();

I agree the C/C++ programmer would see auto and think "stack" but that is a
different problem.

-Ben

"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:bu4uou$6bv$1 digitaldaemon.com...

 But auto instances do not exist on the heap and, for me at least, new says
 "create one of these on the heap".

 I grant you, or anyone else, that new actually has two functions, and my
 focus on the heap side (as opposed to the construction side) is


undoubtedly

 from my C++ thinking


 "C" <dont respond.com> wrote in message
 news:bu4fqf$2guo$1 digitaldaemon.com...

 Honestly I kind of like the current syntax.  I think one of the gotchas
 moving from C++ is forgetting to new everything , if we require the same
 syntax it will drive home that everything must be new'ed.

 C


 "Matthew" <matthew.hat stlsoft.dot.org> wrote in message
 news:bu35b2$bii$1 digitaldaemon.com...

 "Hauke Duden" <H.NS.Duden gmx.net> wrote in message
 news:bu357d$b60$1 digitaldaemon.com...

 Walter wrote:

 "Matthew" <matthew.hat stlsoft.dot.org> wrote in message
 news:bt0gqk$ion$1 digitaldaemon.com...


Walter

A while back I mentioned that it would be nice to allow auto










 instances

 to

 be


constructed without the (syntactically consistent but semantically
misleading) new syntax. In other words

            auto ExeModule xmod =   new ExeModule(moduleName);

could be written as the more accurate

            ExeModule xmod(moduleName);

If memory serves, you liked this, but it's not yet implemented.












Are

 there

plans to do this? Is it as simple as it seems to be to implement?



 As the other respondents pointed out, there are many parsing










issues

 to

 be

 worked out to make this work. I think we'll leave it as is for the






 time

 being.


 What about this one?

 auto ExeModule xmod(moduleName);


 That's good. Can we have that Walter?
Jan 16 2004