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

[Atila Neves]

On Tuesday, 28 April 2020 at 19:44:49 UTC, Arine wrote:
> 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.

https://herbsutter.com/2013/08/12/gotw-94-solution-aaa-style-almost-always-auto/

> 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.

I don't think actual types are important but what you can do with 
them is. It's similar to caring what concrete type an OOP 
instance has. It could be said that instead of auto one should 
use a concept/trait/typeclass instead, and in fact Bjarne has 
argued for the inclusion of something like that for C++.


Instead of:

     auto r1 = r0.map!func;

we'd use:

     InputRange!int r1 = r0.map!func;


Where InputRange(T) is a "compile-time interface" and the 
concrete type can depend on template instantiations.

I think auto right now is overused as a return type though, 
especially when it actually is a concrete type. Even Haskell 
encourages explicit typing of module-level functions.