digitalmars.D - Different types with auto
- bearophile (28/29) Mar 17 2011 I have found this article through Reddit (the Reddit page already contai...
- Jason E. Aten (5/6) Mar 17 2011 If the coder wanted them to all be doubles, it's easy to require that by...
- Jonathan M Davis (13/22) Mar 17 2011 Personally, I hate it when variables are declared no the same line perio...
- KennyTM~ (5/11) Mar 17 2011 auto x1 = templateFunctionWithComplicatedReturnType("a"),
- Andrei Alexandrescu (3/18) Mar 17 2011 Yah, not sure what would ever be bad about that.
- Regan Heath (10/30) Mar 18 2011 Nor is there anything bad about this:
- Nick Sabalausky (9/23) Mar 17 2011 I'm not sure how I feel about D's auto creating multiple types in one
- Jacob Carlborg (4/36) Mar 18 2011 --
- bearophile (7/8) Mar 18 2011 Currently this is mixed with the octal literals discussion:
- Bekenn (2/3) Mar 19 2011 Thank goodness that's under discussion.
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
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
On Thursday, March 17, 2011 13:17:33 Jason E. Aten wrote: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 Davisauto 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
On Mar 18, 11 04:17, Jason E. Aten wrote:auto x1 = templateFunctionWithComplicatedReturnType("a"), x2 = templateFunctionWithComplicatedReturnType("b"), x3 = templateFunctionWithComplicatedReturnType('c'), x4 = templateFunctionWithComplicatedReturnType("d");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
On 3/17/11 7:27 PM, KennyTM~ wrote:On Mar 18, 11 04:17, Jason E. Aten wrote:Yah, not sure what would ever be bad about that. Andreiauto x1 = templateFunctionWithComplicatedReturnType("a"), x2 = templateFunctionWithComplicatedReturnType("b"), x3 = templateFunctionWithComplicatedReturnType('c'), x4 = templateFunctionWithComplicatedReturnType("d");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
On Fri, 18 Mar 2011 00:30:30 -0000, Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:On 3/17/11 7:27 PM, KennyTM~ wrote: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/On Mar 18, 11 04:17, Jason E. Aten wrote:Yah, not sure what would ever be bad about that.auto x1 = templateFunctionWithComplicatedReturnType("a"), x2 = templateFunctionWithComplicatedReturnType("b"), x3 = templateFunctionWithComplicatedReturnType('c'), x4 = templateFunctionWithComplicatedReturnType("d");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 18 2011
"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: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.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=3999I 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
On 2011-03-17 21:35, Nick Sabalausky wrote:"bearophile"<bearophileHUGS lycos.com> wrote in message news:iltdqr$1rd7$1 digitalmars.com...Yes, it must die. It also conflicts with uniform function call syntax.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: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.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.;-- /Jacob CarlborgThere 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=3999I 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 18 2011
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
On 3/18/2011 12:59 PM, bearophile wrote:http://d.puremagic.com/issues/show_bug.cgi?id=2656Thank goodness that's under discussion.
Mar 19 2011