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

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

> 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

----------------------------------------------------------------------------
---

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

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
>

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

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
>

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

"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.

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