auto: useful, annoying or bad practice?

[Jesse Phillips]

On Monday, 30 April 2018 at 21:11:07 UTC, Gerald wrote:
> I'll freely admit I haven't put a ton of thought into this post 
> (never a good start), however I'm genuinely curious what 
> people's feeling are with regards to the auto keyword.
>
> So I'm curious, what's the consensus on auto?

I'll start with auto for declaration and then talk about auto for 
return types.

The main issue with utilizing auto is that a type will lead you 
to documentation on the capabilities of the variable and to 
locate the implementation of the code being called. The desire to 
decouple from the concrete type is admirable but generally the 
desire for the concrete type isn't about coupling with it.

What I find though is that auto doesn't increase the difficulty 
of the objectives I described. What I find is in other languages 
(generally C# and Java) is that you won't be returned a concrete 
type but an interface. This can be nice for capabilities of the 
variable but all to often I find that the API still expects you 
to convert to a concrete type. And you still need to track down 
the actually concrete type to review the actual implementation of 
that function.

I find auto to be very useful for development as I can switch out 
the type be it a class/struct or interface rather easily. I have 
mixed feelings when it comes to debugging. For a stable and 
unchanging interface (concept not construct) it should be avoided.

Use of auto in return type I also like but use sparingly. This is 
because it hides documentation of an API. And I'm not talking 
about the function documentation laking specification of what it 
returns I'm talking about types being a good way to make a point 
of reference. For example an auto function which returns a range 
can easily reference the Range API since it is the D interface 
for iteration. Custom/framework types don't have that luxury.