D's auto keyword

[Lutger]

On 01/13/2010 08:46 PM, retard wrote:
> Wed, 13 Jan 2010 20:22:02 +0100, Lutger wrote:
>
>> On 01/13/2010 05:49 PM, Justin Johansson wrote:
>>> Happy New Year 2010 Everybody.
>>>
>>> Having resumed C++ nationality for the last few months, I kind of miss
>>> D's auto keyword.
>>>
>>> I am wondering, though, from an OO/polymorphism perspective, and UML
>>> and sound software engineering perspective as well, what does D's auto
>>> keyword buy you except (perhaps) laziness (in keystrokes)?
>>
>> A lot:
>>
>> No types to be seen here (aside from the literal 2) so you can: 1.
>> rename the type whatever bar() returns without ripple effects through
>> this code
>> 2. substitute the type itself for another type that obeys the same
>> structural interface.
>>
>> In a way, it's like not using magic numbers only applied to types :) The
>> benefits are not limited too but more pronounced in templated code.
>
> The main benefit IMO is that you don't need to repeat things twice.
>
> sadklaskdjlaj<aslfkjals, asdkjasldjw<asldjalsdm, asdjslk>>  foo = new
> sadklaskdjlaj<aslfkjals, asdkjasldjw<asldjalsdm, asdjslk>>(); // no thanks
>
> Repetition happens every time one uses advanced data structures like
> lists, hashes, tuples etc. In cases like
>
>>
>> auto foo = bar(2);
>> auto baz = grok(foo);
>
> I would actually explicitly write to type some times to document things
> better.

Well I usually don't use names such as foo, bar and baz in production 
code ;) (I suck at naming and have recently started to make long names). 
I get your point but would consider that kind of repetition the least of 
the benefits, since there is no big downside here to copy & paste away.

>> All ML derived languages do this much more extensively and they even
>> don't need an auto keyword for it. C# has var and VB.NET has Dim which
>> mean the same thing. The nice thing with those languages is that if you
>> code in Visual Studio, you only have to hover above the variabele and
>> the type pops up. Most IDE's have this btw, including descent, so that
>> takes away the concern of having to remember the flow of types inferred.
>
> A tru 1337 koder uses vim or emacs, both of which suck at semantic
> analysis :)

Then again, such a koder don't need no pedantic type declarations for 
reminders.