Comment by lumberjackstian | Hacker News Reader

Comment by lumberjackstian | Hacker News Reader

Parent Full thread

lumberjackstian

I've felt this as well, been using D for a couple years now, and this is the kind of thing that just makes me have to context switch more than I'd like. With the current implementation of the language it's hard to avoid, and function's return type can be quite complex, so writing it down can be hard.

Another reason is the (ironically) dynamic nature of a return type. E.g.

auto whatDoesItReturn(int i)() { static if (i == 0) { return int.init; } else { return string.init; } }

Template code can do that quite easily and then you don't have a choice but to write auto as the return value.

What would be fantastic if the documentation could be given access to the the compiler's return type inference, so that it could document the auto returns with a little more info.

Another way useful approach would be to implement protocols like in swift, or traits like in scala/rust/others, signatures in ml, etc. Then you would be able to define the interface of what a function returns.

> auto whatDoesItReturn(int i)() { static if (i == 0) { return int.init; } else { return string.init; } }

I agree with your point, but for the sake of the audience who doesn't know D I think this example is misleading, as one could take the "int i" parameter as a runtime one, while it's actually a compile time one (the equivalent of C++ non-type template parameter). If you instantiate the function with 0 as a compile-time parameter, it is a function that returns int; otherwise it's a function that returns string. It is never a function that can return int or string.

Yeah I realise I could've explained a bit more about template arguments indeed! The point was that it can be hard to specify the return type.

Yes, this is the problem for returns, but it's going to be difficult for the compiler to put something useful. The best it can do is point you at the code that returns, and let you figure it out.

I still think the best option is let the author describe it in ddoc, as the semantic meaning can be much easier to convey that way.

I haven't looked at D yet, but... yuck! `var` for return types in a method signature is seriously unhelpful!

If the docs are filled with this, then D is certainly coming off my list of langs to look at.

For functions that can return different types, I think interfaces or union types would be more helpful (not sure if D supports either though).

Yes, it supports interfaces and unions. One thing not being stated enough in this thread also is that the docs are not just a regurgitated version of the prototypes -- there's actual hand-written text that tells you what the things return.

In the standard library, it's primarily in the range-based functions that you see this, where the type doesn't generally need to be known. And where you do see it, the documentation will describe what the function returns more accurately than any convoluted made-up type the function signature could show you.

What would be the return type of that? Does D have an Either type?

Depends on the value of the template parameter. If it's 0 the return type is an int, if it's not 0 the return type is a string.

There's a wanting implementation of a sumtype in the standard library (https://dlang.org/phobos/std_variant.html#.Algebraic), and a much better one as a package: https://code.dlang.org/packages/sumtype

Interesting, so the return type isn't known until runtime.

When it comes to templates it's not until instantiation time - when the compiler see the code being used. So this is just an issue during compilation.

The docs on static if may shed some more light: https://dlang.org/spec/version.html#staticif

So the previous code wouldn't compile unless the compiler knew what values were going to be passed into whatDoesItReturn?

I missed this the first time, but there are two sets of parentheses in the example. Apparently the first set are like template parameters, and the second are the actual arguments to the function.

Aye correct! I should've been more clear about that, sorry.

Template arguments need to be known at compile time, and the extra set of parens is how templates parameters are declared in D.

No. It is known at compile time.

Template declarations in D take 2 parameter lists. The first is the template parameters the second the runtime parameter: in auto whatDoesItReturn(int i)() { static if (i == 0) { return int.init; } else { return string.init; } }

we have (int i) as template parameter and () as an empty runtime parameter. In C++ syntax whatDoesItReturn<int i>()

at instanciation the syntax is different:

whatDoesItReturn!0() will instantiate a function returning an int

whatDoesItReturn!42() will instantiate a function returning a string.

Reply on news.ycombinator.com