[schveiguy]

This wouldn't work for D. D doesn't constrain return types to something less than what they are. A Range is not just an Iterator, it has optional pieces that depend completely on the given type.

For example, the return of map could provide indexing, or it could provide forward and backward iteration, or it might have methods that are completely unrelated to the type.

There is no good reasonable and non-confusing way to describe all the things map could return depending on the input. It's much better to just describe it conceptually in the human-readable docs, and let the person understand the result.

I'll note that just above the function map in D's source is the documentation. You just need a little more context, and it will describe what map returns in a much more (IMO) useful fashion than a return type that might be several lines long and consist of various static conditionals:

"The call map!(fun)(range) returns a range of which elements are obtained by applying fun(a) left to right for all elements a in range."

This is the difference between duck typing and generics.

[fluffything]

> For example, the return of map could provide indexing,

You can provide more interfaces in Rust:

    fn map(...) -> impl Iterator<Item=U> + Index<Target=U>

but you can't provide "conditional" interfaces (for most interfaces at least), e.g., this won't work:

    fn map(...) -> impl Iterator<Item=U> + ?Index<Target=U>

where `?Index` reads as "maybe implements Index".

To allow that you would essentially need to say that "if the input implements `Index`, the output implements `Index`":

    fn map<U, T, F, I, O>(it: I) -> O
        where I: Iterator<Item=T>, U: From<T>,
              O: impl Iterator<Item=U>,
              I:?Index<Target=T> -> O:?Index<Target=U>
    {
        it.map(|t| From::from(t))
    }

The type system implementation already supports these types of constraints, but there isn't a language extension that exposes that. I don't see any fundamental reasons that make this impossible, but there are many trade-offs involved.

Notice that, for example, the output Range does not implement the same interfaces as the input range, e.g., the input Range implements an `Index` interface over a range of `T`s, but the output Range implements an `Index` interface over a range of `U`s. In D this is super implicit in the implementation details (body) of an equivalent `map` function, but in Rust it needs to be part of the type signature to avoid changes to a function body to silently cause API breaking changes. In D, you could change the body of map to map only from Range(T) -> Range(T), without changing its interface, and that would break all code using it to map a Range(T)->Range(U).

[kazinator]

Though it doesn't work for D, it could work for the documentation of D (what is being discussed), in some usefully hand-wavy way.

If I'm working in a typed language, and are dealing with functions max(a, b, c) and list(a, b, c), I would expect the documentation to say that one returns T, whereas the other a list(T). If it says auto, then I'm guessing from the names.

Maybe the target audience is programmers familiar with dynamic languages, who don't care so much and are used to reading the descriptions of functions about what is returned.

[the8472]

In rust this would be expressed as multiple impl blocks with different generic parameters which show up as such in the documentation.

https://doc.rust-lang.org/std/vec/struct.Vec.html#implementa...

[schveiguy]

What am I looking at there? Are those all traits on Vec that I then have to parse mentally so I can understand what I can do with it? Are all those pages basically to say "Vec works like an array of T"?

I've dealt with generics in other languages such as Swift and C#, and they were substandard to D's templates IMO. I remember in C#, I could not get a simple generic function that accepted both a string and Int to work, so I just gave up and wrote multiple functions without generics.

I'm sure some people find this documentation helpful, but it doesn't look as useful to me as map's simple one-liner.

[masklinn]

> What am I looking at there? Are those all traits on Vec that I then have to parse mentally so I can understand what I can do with it? Are all those pages basically to say "Vec works like an array of T"?

No. The type which tells you that Vec works like a slice of T is https://doc.rust-lang.org/std/vec/struct.Vec.html#impl-Deref

The others are separate abstract operations which are available (implemented) on vecs e.g. AsRef/AsMut denote that you can trivially get a (mutable) reference to the parameter from a vec. The implementations are similarly trivial (https://doc.rust-lang.org/src/alloc/vec.rs.html#2348-2374).

> I'm sure some people find this documentation helpful, but it doesn't look as useful to me as map's simple one-liner.

Do you mean this one?

    auto auto map(Range) (Range r)

[DougBTX]

I’ve not looked much into D, but I’ve really been enjoying Rust.

I think the main takeaway is that there are very different ways of approaching language design. In Rust there was a decision to make the function signature the single place which defines the guaranteed input and output types to a function, but that is a trade-off. It encourages a more complex type system, as the flexibility of functions is on a sense constrained by the type system. Personally I like that explicitness, since there is only one place to look. In the future features like const generics and GATs will make that more powerful.

But on the other hand, D appears to be able to support much more complex types (possibly dependent types?) by not requiring that the type system can express them directly. In a sense the whole language can be used to define types. That’s a cool thing to be able to do, even if it means having to inspect documentation and method bodies to work out what they do.

[1980phipsi]

On the "auto auto", I'm pretty sure I filed a bug report on that. There are alternate D docs that don't produce the "auto auto" (and it goes without saying that it isn't that way in the code itself).

[schveiguy]

No this one:

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

[DougBTX]

To get that degree of flexibility in Rust you’d have to turn to macros, then the return type will depend on the generated code. That could be pretty much anything, so you’d need to read the docs anyway. Perhaps the languages are not that different after all.

D’s syntax for the template body looks much more similar to normal D code, in Rust the pattern macro syntax is like a language to itself and procedural macros need a fair bit of boilerplate, including explicit “quote” blocks.

[gmueckl]

This looks insane, mostly because there must be some repeated code in all these impls.

The D way of solving this is to statically query the properties of the passed in type at compile time whenever a part of the template needs to be specialized. It can make for very concise code, but you can't name the exact input type with this approach.

[fluffything]

I don't think that's what the OP is talking about.

They want to have a generic function that returns opaque types implementing different interfaces depending on the inputs. I've replied to that above.