We're #1 on Hacker News at the moment!

Arine arine1283798123 at gmail.com
Tue Apr 28 19:44:49 UTC 2020


On Tuesday, 28 April 2020 at 18:57:37 UTC, welkam wrote:
> On Tuesday, 28 April 2020 at 18:25:28 UTC, Ethan wrote:
>> On Tuesday, 28 April 2020 at 17:06:03 UTC, Adam D. Ruppe wrote:
>>> Type inference itself isn't bad, but the auto in 
>>> documentation is something I agree isn't great.
>>
>> My hot take after years of explicit typing (remember manual 
>> for iterator loops in C++?) and more D metaprogramming than 
>> most is that "auto is perfect for things you don't intend the 
>> user to store".
>>
>> Since that's all that anti-auto arguments come down to here - 
>> the only rational reason you need to know the return type of a 
>> function is that you intend on storing it somewhere. And 
>> that's kinda pointless with ranges returned by std.algorithm 
>> for example.
>>
>> Perhaps there's actually a design win to be had here if we can 
>> define nostore or something like that as a return qualifier...
>
> My take on all those that insist on explicit return types is 
> that they have spent long time writing in C and/or C++ and then 
> tried to code in D without learning the language first. Because 
> D doesnt behave the same as their previous languages they have 
> difficulties using the language. Then they proceed to blame 
> external world for their problems.

C++ has auto, it is discouraged to be used frequently unless 
where it is actually required or of benefit. Otherwise it makes 
code harder to read and the only benefit then is that it is just 
easier to write because the programmer is to lazy to put the 
actual type instead. When you have to dig through templated 
functions that all just return `auto`, it just encourages the 
user to use auto as well when they wouldn't have to.


More information about the Digitalmars-d mailing list