[self_awareness]

I've never programmed in D so I don't know, but from curiosity I wanted to check if what you write is true. However, I can't find any function that is declared as auto.

Could you please paste some example of a function that has a return value which is declared as auto?

[bachmeier]

Here's one example:

https://dlang.org/phobos/std_algorithm_sorting.html#partitio...

The important line is

auto pieces = partition3(a, 4);

So, what's the type of pieces? The D standard library is written to be generic. And sure enough, that line of code will run. Where it turns into a problem is when you try to do something with it. If pieces is a range, there are certain things you can't do with it. Or maybe you can. Who knows. You'll never learn it from reading the documentation. I've been using D since 2013 and I still struggle with this at times. It's a valid complaint. (D's a great language, but is short on manpower to fix rough edges like this.)

[schveiguy]

> You'll never learn it from reading the documentation.

Did you not see the Returns section from that link?

"Returns: A std.typecons.Tuple of the three resulting ranges. These ranges are slices of the original range."

Further note: If you just saw `std.typecons.Tuple!(typeof(Range.init[0 .. $]), typeof(Range.init[0 .. $]), typeof(Range.init[0 .. $]))` which is what would have to be written there instead of auto, would that make you feel better? Do you not have to read the documentation to figure out what the function does or what actually goes into those tuples?

[F-0X]

The major examples are parts of the stdlib which offer higher-level pipelines (some answers here indicate the need for such things to be very flexible in their return values to allow this, but this is not a priori obvious - Java manages similar functionality with just the Stream<T> class after all).

In this (and the sibling pages in algorithm) nearly every entry is listed as either "template" or "auto" relhttps://dlang.org/phobos/std_algorithm_iteration.html

[aldacron]

D's classes and interfaces are much like Java's, so it's possible and easy to write functions that express return types like that. It's also quite restrictive for generic programming. D's metaprogramming features are much more powerful. That means a template can return different types that do not conform to a single, easily-expressed interface. The std.algorithm package is built on that concept.

[masklinn]

https://dlang.org/library/std/algorithm/iteration/map.map.ht...

    auto auto map(Range) ( 
      Range r 
    )

[EvenThisAcronym]

Returns

A range with each fun applied to all the elements. If there is more than one fun, the element type will be Tuple containing one element for each fun.

[masklinn]

Yes, D has prosaic descriptions. So does Python. Or Ruby.

Maybe read and try to understand the complaint instead of pointing out something unrelated?

[takeda]

Maybe it was fixed? I would imagine that saying in documentation that return type is auto is equivalent to not mentioning return type at all, so feels like something not intentional.

[masklinn]

> Maybe it was fixed?

It wasn't. They probably didn't look into the more "generic" functions e.g. hofs and algorithms.

The vast majority of functions in https://dlang.org/phobos/std_algorithm_iteration.html returns "auto"

[dgellow]

I checked your link, each function has a “Returns:” section that describe what to expect. Isn’t that what you want from a documentation?

[lostmsu]

A type is much denser, than a textual description, and in most cases sufficient.

[ben-schaaf]

Having each of the generic range functions return a <FN>Result type that all implement some variations of a random access range is absurd. Having "auto map(); Returns an input range" is much denser and helpful than "MapResult map(); struct MapResult { @property bool isEmpty(); ...}".

A more explicit "impl(InputRange) map()" may be better until you consider that map is generic on the kind of range you give it, so that just turns into "impl(MapResult!R) map(R)()". A more roundabout, pointless way of saying "auto".

[gallier2]

> A type is much denser, than a textual description, and in most >cases sufficient.

In feeble languages with simpleton typesystem may be, but in highly generic templated language like D it is not the case. The type is not dense at all.

What's funny is that in general people complain that compiler errors in D are unreadable. You know why they are unreadable?

Because they print out the types of the functions in which the error occurs and that is nothing more than word salad for generic functions.

Types with hundreds of characters are very common.

[dgellow]

Depends the type, it can be quite long and complicated. I always have a lot of issues trying to read return types from templated functions in C++ because they look really messy.

[lostmsu]

Perhaps then it would make sense to shorten types in a smart way.