Has the ban on returning function nested structs been lifted?

[bearophile]

Jonathan M Davis:

> Actually, the coolest part about it IMHO is that it highlights the fact that you 
> should be using auto with std.algorithm and _not_ care about the exact types of 
> the return types. Knowing the exact return type for those functions is generally 
> unnecessary and is often scary anyway (especially with the functions which 
> return lazy ranges like map and until). Making the functions return auto and 
> completely hiding the return type pretty much forces the issue. There's still 
> likely to be some confusion for those new to D, but it makes the proper way to 
> use std.algorithm more obvious. I'd hate to deal with any code which used 
> std.algorithm without auto. That would get ugly _fast_.

auto variable inference is indeed almost necessary if you want to use lazy functions as the ones in Phobos. But I have to say that those types are scary because of the current design of those Phobos higher order functions. In Haskell if you have an iterable and you perform a map on it using a function that returns an int, you produce something like a [Int], that's a lazy list of machine integers. This is a very simple type. If you perform another map on that list, and the mapping function returns an int again, the type of the whole result is [Int] still. The type you work with doesn't grow more and more as with Phobos functions. Designers of C# LINQ have found a more complex solution, they build a tree of lazy delegates...

Bye,
bearophile