Hacker News new | ask | show | jobs
by gallier2 2239 days ago
> That should not be a problem. It is a problem in D because of a lacking in D.

It is not a problem, the compiler copes with it. The problem comes from the fact that such a type is absolutely not interesting to know how it is written. The unmangled type is unreadable.
1 comments
asdkjh345fd 2239 days ago
Yes, the type is very interesting to know. That's why other languages make it known. Ignoring the entire discussion to reply twice with "nu uh!" is not very productive.
link
aldacron 2239 days ago
There's usually no reason to know the return type of any range-based function in D. It's not like auto is applied as a return type willy nilly. And anyone who understands D's ranges and how they are used should have no problem seeing a function declaration that returns auto.
link
asdkjh345fd 2238 days ago
Right, the entire world is wrong because you can't admit a fault in a random piece of software you are emotionally invested in. Makes sense.
link
aldacron 2238 days ago
Not quite. I'm saying that in this case it doesn't matter because of the way the API is used. Is it confusing for people who don't understand D ranges? Yes, it certainly can be. It was for me when ranges first came along. But once you understand how D ranges are intended to be used, then you realize you rarely ever care what the return type is. D is not Rust, or C++, or (insert language here).

When the return type actually matters, auto should be avoided unless there's no way around it. But that's why we have "Returns:" in Ddoc. The function signature itself is not the complete documentation. I mean, you're acting like all D functions are documented to return auto. They aren't. It's used where it needs to be.

link