'auto' in the sense that C# and other languages use 'var' makes perfect sense. There is nothing wrong with it and it takes out redundant 'noise':

    var i = "This is a string"; // don't need to know two times that this is a string.
    var j = SomethingThatReturns(); // IDE or function docs will have my back here...

FYI, I wouldn't use this for 'time saving'. It's to take out redundant noise, which can clutter code. It also enables easy switching of return types from methods which occasionally means you don't have to change any code. It is frequent the type you change it to might follow the same protocol/interface as the previous type. Or you are just not using anything special with the type (maybe just forwarding a return). I do a ton of C# code and it's common with the .NET framework that this happens (for instance when working with collections). In short 'auto' or 'var' is not for time saving. It's to increase code readability and code refactorability. Those are it's benefits worth a damn.

Most people spend more time reading code than writing code so if you are worried about the time it takes to type out 'auto' vs. 'SomeObnoxiouslyLongAndOverlyVerboseTypeName' then I think you are turning an anthill into a mountain. It's one thing when a language feature takes away the need to write hundreds of lines of common boiler plate code, but when it just prevents you from typing out a really long name? Come on...please...that's not why 'auto'/'var' has gained industry recognition. There's just a lot of people that use it because it's an idiom without taking the time to understanding why it _is_ an idiom. So they say things like 'I type less, so I like it'.

Which brings me to where it probably is not a good place for it...in the return fadeclaration of a function/method. I'm very close to saying, even after having read some of the comments that try justifying it, that 100% of the time you want to specify the return type. When you create a function that returns something, you are actively deciding 'I need to return this thing, this is useful or the point of this function'. To not have that thing obviously spelled out in the API is a huge design mistake. Not only do you take away a self-documenting part of you function definition, you make someone have to either have a good IDE (which some people are adverse to using) or actually go read the source code. To not put the effort into thinking about the type (or constraints on the type when dealing with generic/templated code) is just lazy. And worse, it will facilitate libraries where people didn't think about their API as much as they should.

On Sunday, 20 May 2018 at 00:44:13 UTC, I love Ice Cream wrote:
> Which brings me to where it probably is not a good place for it...in the return fadeclaration of a function/method. I'm very close to saying, even after having read some of the comments that try justifying it, that 100% of the time you want to specify the return type. When you create a function that returns something, you are actively deciding 'I need to return this thing, this is useful or the point of this function'. To not have that thing obviously spelled out in the API is a huge design mistake. Not only do you take away a self-documenting part of you function definition, you make someone have to either have a good IDE (which some people are adverse to using) or actually go read the source code. To not put the effort into thinking about the type (or constraints on the type when dealing with generic/templated code) is just lazy. And worse, it will facilitate libraries where people didn't think about their API as much as they should.

The return type for range-oriented functions in std.algorithm is usually not terribly useful. You get a range whose capabilities depend on the type of range you pass in, so you have to read the source code in any case. But at least listing the actual return type lets you skip some reading.

This design by introspection stuff is powerful, but it's unfriendly toward people trying to understand your code.

D is very hard to make an IDE for that would actually tell you what type the return value is. `pragma(msg, typeof(foo))` is probably your best bet, and that's kind of terrible.

Oh, there's also one other use of `auto` return types that I haven't seen mentioned before: it functions as a DMD pragma to include the function in generated .di files. Wretched, no?

On Sunday, 20 May 2018 at 02:34:38 UTC, Neia Neutuladh wrote:
> The return type for range-oriented functions in std.algorithm is usually not terribly useful.

So the first question that comes to my mind are what are the 'rules' of the output. Which is really what typing is. It's a series of rules. Your object is allowed to call these methods/properties. It is 'this' size. Languages have generic returns. D is not the only language with a concept of returning a 'compiler determined type'. But the rules are always baked into the API. If it's not, it's a design failure and more thought should be put into it.

The only place I wouldn't be so strict with auto returns is in private methods. However, I still might tell someone to think about what they are trying to return there. It's not an unimportant piece of the API.

On Sunday, 20 May 2018 at 02:34:38 UTC, Neia Neutuladh wrote:
> D is very hard to make an IDE for that would actually tell you what type the return value is.

This might sound a little hard, but that's probably a fundamental failure of the D language and explains some of the poor tooling around the language.

On Sunday, May 20, 2018 14:33:16 I love Ice Cream via Digitalmars-d wrote:
> On Sunday, 20 May 2018 at 02:34:38 UTC, Neia Neutuladh wrote:
> > The return type for range-oriented functions in std.algorithm is usually not terribly useful.
>
> So the first question that comes to my mind are what are the 'rules' of the output. Which is really what typing is. It's a series of rules. Your object is allowed to call these methods/properties. It is 'this' size. Languages have generic returns. D is not the only language with a concept of returning a 'compiler determined type'. But the rules are always baked into the API. If it's not, it's a design failure and more thought should be put into it.
>
> The only place I wouldn't be so strict with auto returns is in private methods. However, I still might tell someone to think about what they are trying to return there. It's not an unimportant piece of the API.

That's where you get into a combination of needing good documentation and needing to know what set of traits to use to test the type to see what functionality it has. But for better or worse, asking a type what it can do is a key piece of Design by Introspection. The result can be extremely powerful, as Andrei has talked about on multiple occasions (I'd suggest watching his dconf 2015 talk about it if you haven't), but it does place a higher burden on the programmer to figure out how to use a type. So, there are pros and cons. Ultimately, auto can be extemely useful, and much of what we do with D really wouldn't be reasonably feasible without it, but it also needs to be used intelligently, because while it does bring some serious benefits, it can be at the cost of clarity if used poorly.

- Jonathan M Davis

On Sunday, 20 May 2018 at 14:35:21 UTC, I love Ice Cream wrote:
> On Sunday, 20 May 2018 at 02:34:38 UTC, Neia Neutuladh wrote:
>> D is very hard to make an IDE for that would actually tell you what type the return value is.
>
> This might sound a little hard, but that's probably a fundamental failure of the D language and explains some of the poor tooling around the language.

This is specifically when metaprogramming is going on.

Most programming languages these days fall into one of three categories:

* They don't support metaprogramming.
* They support metaprogramming by reflection only, like Java and Go. As soon as you use any metaprogramming, your IDE can't tell you what types things are; you've got interface{} or Object and you're calling Field.get() and Method.invoke().
* They support metaprogramming by merit of being a dynamic language. As soon as you write a line of code, your IDE can't tell you what types things are.

If you write D without any metaprogramming, it's as easy to write an IDE for that as for Java.

The problem is that metaprogramming is useful, and in D it's not that hard, so we use it a lot. There are proposals floating around for "concepts" or "signatures" (basically, compile-time interfaces) that would help out a lot, but nobody's driven one of those proposals to completion, as far as I know.

auto has its uses, but it's wildly overused, especially in library code and documentation, and really, really, *really* much so in documentation examples.


On 05/01/2018 06:09 AM, Craig Dillabaugh via Digitalmars-d wrote:
> 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.
>>
>> Speaking for myself, I dislike the auto keyword. Some of this is because I have a preference for static languages and I find auto adds ambiguity with little benefit. Additionally, I find it annoying that the phobos documentation relies heavily on auto obscuring return types and making it a bit more difficult to follow what is happening which gives me a bad taste for it.
>>
> clip
>>
>> So I'm curious, what's the consensus on auto?
>
> As some have pointed out, it certainly has value. For example, in functions returning ranges, etc. where you wouldn't want to have to write out the whole type.
>
> However, as an infrequent D user I admit I prefer to see the actual type where it is feasible, as I find 'auto' is a barrier to understanding to someone who isn't familiar with a particular piece of code.  I would never use auto in place of a basic type.
>
>

On Sunday, 20 May 2018 at 23:01:39 UTC, Charles Hixson wrote:
> auto has its uses, but it's wildly overused, especially in library code and documentation, and really, really, *really* much so in documentation examples.
>
>

A lot of functions in `std.algorithm` are actually quite clear about it, e.g. `splitter`:

"auto splitter(alias pred = "a == b", Range, Separator)(Range r, Separator s)
...
Returns:
An input range of the subranges of elements between separators. If r is a forward range or bidirectional range, the returned range will be likewise. When a range is used a separator, bidirectionality isn't possible."

So it obviously returns a range which you can process as a range. No need to know about the exact type (which may change). All you need to know is that it adheres to a minimal range interface (r.empty, r.front, r.popFront). Without `auto`, it'd be a solid mess and generics would become more or less useless.

Even Java is moving into this direction and it makes sense for a lot of day to day issues, programmes will increasingly demand it. Code like the following is much more elegant than using the ould for loop:

JSONObject jitems = new JSONObject();
data.entrySet()
          .forEach(i -> { jitems.put(i.getKey(), i.getValue()); });