bearophile wrote: > This discussion clearly shows that the current semantics of the "auto" is not > clean enough and it needs to be improved. > To improve it D needs to adopt the strategy of using all attributes in a more > tidy and semantically clean way, as Java does. Java doesn't compile "useless" > or wrong attributes as D sometimes does. > > So it can be better to this to be a compilation error: > enum x = 10; > And accept only: > auto enum x = 10; > Or: > int enum x = 10; > > Such tidy enforcement of attributes can be seen as fussy and sometimes it > requires extra compilations to remove all the mistakes, but it helps the > programmer understand in less time the semantics of those attributes. In > pedagogy it's well known that when a student is learning something, it's much > better if the rules are enforced in a strict way at the beginning. > > And I'd like in D2 the "override" to be always necessary (even when the code > is not compiled with "-w") as in C#, to avoid other bugs. I can show an > example of such possible bugs. > > Bye, > bearophile
I don't like it. And I don't think the suggested alternatives make the situation any better. Using 'var' from C# has the benefit of making D look like C#, but I don't see it as less verbose (it also says to me duck-typing). And Go's := hides even more information than the current situation. The issue this thread is showing is that what 'auto' means is not well defined in the documentation. Storage classes already have intricate rules on who can be used where and with whome. And having 'auto ref' won't help.
