www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Different types with auto

reply bearophile <bearophileHUGS lycos.com> writes:
I have found this article through Reddit (the Reddit page already contains
comments by Andrei), "C++0x feature support in GCC 4.5" by Arpan Sen:
http://www.ibm.com/developerworks/aix/library/au-gcc/index.html

The article probably doesn't contain new things for people that have closely
followed the design and development of C++0x, but for less experienced people
it shows several D features that are now more or less present in C++ too (as
soon as C++ compilers catch up).

One thing of that page has caught my attention, in Listing 7, about erroneous
use of the auto keyword:

int main( )
{
   auto i = 9, j = 8.2; // error – i and j should be same type
   auto k = &k; // dumb error – can’t declare and use in initializer
   ...
}

According to the article the first line generates the error:
1.cpp:3:8: error: inconsistent deduction for 'auto': 'int' and then 'double'

This is a difference between D auto and C++0x auto, because this is accepoted
by D:

void main() {
   auto i = 9, j = 8.2;
}


There was a thread about related matters in the d.learn newsgroup, started by
Ellery Newcomer:
http://www.mail-archive.com/digitalmars-d-learn puremagic.com/msg09361.html


D disallows bug-prone C syntax like this (C style guides strongly suggest to
declare only each variable in a distinct statement and line of code):

int a = 1, *b = null;

D accepts code like:

 auto a = 1, b = null;
This seems against the D rule of not allowing different types to be initialized in the same statement. In my opinion on this design detail D is worse than C++0x. As an example, if you write a line of code like this, meaning it to initialize six double variables, you have a bug: auto x1=1., x2=2., x3=3., x4=4., x5=5, x6=6.; ------------------------- There are only few (one?) other thing(s) that I think C++0x gets better than D, like a more strict enum, I don't understand why D doesn't follows C++0x design on this other detail: http://d.puremagic.com/issues/show_bug.cgi?id=3999 Bye, bearophile
Mar 17 2011
next sibling parent reply "Jason E. Aten" <j.e.aten gmail.com> writes:
 auto x1=1., x2=2., x3=3., x4=4., x5=5, x6=6.;
If the coder wanted them to all be doubles, it's easy to require that by just saying so, and then even x5 will be a double. double x1=1., x2=2, ... So it seems to me that auto does exactly what you asked it to here, and I actually prefer this behavior for conciseness and expressiveness sake.
Mar 17 2011
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, March 17, 2011 13:17:33 Jason E. Aten wrote:
 auto x1=1., x2=2., x3=3., x4=4., x5=5, x6=6.;
If the coder wanted them to all be doubles, it's easy to require that by just saying so, and then even x5 will be a double. double x1=1., x2=2, ... So it seems to me that auto does exactly what you asked it to here, and I actually prefer this behavior for conciseness and expressiveness sake.
Personally, I hate it when variables are declared no the same line period, and I find the fact that auto allows you to have multiple variables on the same line to be inconsistent with other declarations. Just because auto infers the type doesn't mean that they variables being declared with it shouldn't all have the same type. I was _very_ surprised when I learned that auto allowed you to declare different types of variables on the same line, and I think that it's definitely bad. But since pretty much the only time that I ever declare multiple variables on the same line is before the condition of a for loop, it's not like it's causing me any grief either way. And if I react negatively to it in code, I'm already reacting negatively to someone having declared multiple variables on the same line anyway. - Jonathan M Davis
Mar 17 2011
prev sibling parent reply KennyTM~ <kennytm gmail.com> writes:
On Mar 18, 11 04:17, Jason E. Aten wrote:
 auto x1=1., x2=2., x3=3., x4=4., x5=5, x6=6.;
If the coder wanted them to all be doubles, it's easy to require that by just saying so, and then even x5 will be a double. double x1=1., x2=2, ... So it seems to me that auto does exactly what you asked it to here, and I actually prefer this behavior for conciseness and expressiveness sake.
auto x1 = templateFunctionWithComplicatedReturnType("a"), x2 = templateFunctionWithComplicatedReturnType("b"), x3 = templateFunctionWithComplicatedReturnType('c'), x4 = templateFunctionWithComplicatedReturnType("d");
Mar 17 2011
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/17/11 7:27 PM, KennyTM~ wrote:
 On Mar 18, 11 04:17, Jason E. Aten wrote:
 auto x1=1., x2=2., x3=3., x4=4., x5=5, x6=6.;
If the coder wanted them to all be doubles, it's easy to require that by just saying so, and then even x5 will be a double. double x1=1., x2=2, ... So it seems to me that auto does exactly what you asked it to here, and I actually prefer this behavior for conciseness and expressiveness sake.
auto x1 = templateFunctionWithComplicatedReturnType("a"), x2 = templateFunctionWithComplicatedReturnType("b"), x3 = templateFunctionWithComplicatedReturnType('c'), x4 = templateFunctionWithComplicatedReturnType("d");
Yah, not sure what would ever be bad about that. Andrei
Mar 17 2011
parent "Regan Heath" <regan netmail.co.nz> writes:
On Fri, 18 Mar 2011 00:30:30 -0000, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 On 3/17/11 7:27 PM, KennyTM~ wrote:
 On Mar 18, 11 04:17, Jason E. Aten wrote:
 auto x1=1., x2=2., x3=3., x4=4., x5=5, x6=6.;
If the coder wanted them to all be doubles, it's easy to require that by just saying so, and then even x5 will be a double. double x1=1., x2=2, ... So it seems to me that auto does exactly what you asked it to here, and I actually prefer this behavior for conciseness and expressiveness sake.
auto x1 = templateFunctionWithComplicatedReturnType("a"), x2 = templateFunctionWithComplicatedReturnType("b"), x3 = templateFunctionWithComplicatedReturnType('c'), x4 = templateFunctionWithComplicatedReturnType("d");
Yah, not sure what would ever be bad about that.
Nor is there anything bad about this: auto x1 = templateFunctionWithComplicatedReturnType("a"); auto x2 = templateFunctionWithComplicatedReturnType("b"); auto x3 = templateFunctionWithComplicatedReturnType('c'); auto x4 = templateFunctionWithComplicatedReturnType("d"); in fact, it lines up neatly so I prefer it :P -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Mar 18 2011
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:iltdqr$1rd7$1 digitalmars.com...
 D disallows bug-prone C syntax like this (C style guides strongly suggest 
 to declare only each variable in a distinct statement and line of code):

 int a = 1, *b = null;

 D accepts code like:

 auto a = 1, b = null;
This seems against the D rule of not allowing different types to be initialized in the same statement. In my opinion on this design detail D is worse than C++0x. As an example, if you write a line of code like this, meaning it to initialize six double variables, you have a bug: auto x1=1., x2=2., x3=3., x4=4., x5=5, x6=6.;
I'm not sure how I feel about D's auto creating multiple types in one statement. But at the very least, I think your code above is yet another good example of why "1." and ".1" float-literal syntax needs to die, die, die. It does what? Saves one character just so it can be less readable and cause syntax problems for new potential features? Bah.
 There are only few (one?) other thing(s) that I think C++0x gets better 
 than D, like a more strict enum, I don't understand why D doesn't follows 
 C++0x design on this other detail:
 http://d.puremagic.com/issues/show_bug.cgi?id=3999
I agree that would be nice. Weak typing like that is one of the reasons I abandoned C/C++, but D still holds on to it in this particular case.
Mar 17 2011
parent reply Jacob Carlborg <doob me.com> writes:
On 2011-03-17 21:35, Nick Sabalausky wrote:
 "bearophile"<bearophileHUGS lycos.com>  wrote in message
 news:iltdqr$1rd7$1 digitalmars.com...
 D disallows bug-prone C syntax like this (C style guides strongly suggest
 to declare only each variable in a distinct statement and line of code):

 int a = 1, *b = null;

 D accepts code like:

 auto a = 1, b = null;
This seems against the D rule of not allowing different types to be initialized in the same statement. In my opinion on this design detail D is worse than C++0x. As an example, if you write a line of code like this, meaning it to initialize six double variables, you have a bug: auto x1=1., x2=2., x3=3., x4=4., x5=5, x6=6.;
I'm not sure how I feel about D's auto creating multiple types in one statement. But at the very least, I think your code above is yet another good example of why "1." and ".1" float-literal syntax needs to die, die, die. It does what? Saves one character just so it can be less readable and cause syntax problems for new potential features? Bah.
Yes, it must die. It also conflicts with uniform function call syntax.
 There are only few (one?) other thing(s) that I think C++0x gets better
 than D, like a more strict enum, I don't understand why D doesn't follows
 C++0x design on this other detail:
 http://d.puremagic.com/issues/show_bug.cgi?id=3999
I agree that would be nice. Weak typing like that is one of the reasons I abandoned C/C++, but D still holds on to it in this particular case.
-- /Jacob Carlborg
Mar 18 2011
parent reply bearophile <bearophileHUGS lycos.com> writes:
Jacob Carlborg:

 Yes, it must die. It also conflicts with uniform function call syntax.
Currently this is mixed with the octal literals discussion: http://d.puremagic.com/issues/show_bug.cgi?id=2656 http://d.puremagic.com/issues/show_bug.cgi?id=3837 But I think it's better to move it to a specific enhancement request about FP literals only. Bye, bearophile
Mar 18 2011
parent Bekenn <leaveme alone.com> writes:
On 3/18/2011 12:59 PM, bearophile wrote:
 http://d.puremagic.com/issues/show_bug.cgi?id=2656
Thank goodness that's under discussion.
Mar 19 2011