Has the ban on returning function nested structs been lifted?

[Jonathan M Davis]

On Friday, March 18, 2011 15:48:53 bearophile wrote:
> 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...

You get the simple types in Haskell, because _everything_ in Haskell is lazy. 
_Nothing_ is actually computed until it has to be. So, the fact that a list is 
lazily executed doesn't really affect the type system. Not everything is lazy in 
D, so that doesn't work.

And honestly, while the return type of functions like map and until may look 
fairly ugly, auto makes their ugliness pretty much irrelevant. I think that D 
has a solid solution. Haskell looks cleaner only because it forces laziness on 
everything.

- Jonathan M Davis