[Issue 7177] $ should forward to length by default

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=7177



--- Comment #53 from Jonathan M Davis <jmdavisProg at gmx.com> 2013-03-26 19:22:26 PDT ---
Implementing it in the language has the advantage of avoiding making it so that
opDollar works with UFCS and avoids the risk of someone overloading opDollar in
another module and causing stuff to break when it clashes with the one in
std.range. It has the disadvantage of not working for infinite ranges while
also making $ mean length in cases when we don't want it to, forcing us to
@disable it.

Implementing it in the library has the advantage of making it only work with
ranges (unless another overload of opDollar is created for non-ranges) and
making it so that it works with infinite ranges. But it has the disadvantage of
allowing opDollar to be used with UFCS and risks conflicts if other code also
overloads it that way.

However, even if we go with the library route, opSlice will still have to
explicitly support the type that opDollar returns, so it can't really be
supported automatically for infinite ranges. We just save them the trouble of
actually aliasing the type to opDollar and make it so that there's a standard
type to use with infinite ranges and opDollar (which we could already do by
simply declaring something like std.range.InfiniteDollar with the idea that all
infinite ranges with slicing would alias it to opDollar and use it with
opSlice).

So, I don't think that it really matters which way we go as far as infinite
ranges go. In either case, some work is required to support it, and requiring
opDollar on infinite ranges with slicing will break code (though likely not a
lot, since infinite ranges are likely to be a lot rarer than finite ones, and
sliceable ones even more so).

I think that it mainly comes down to whether we'd rather require that types
with length in addition to opIndex and/or opSlice @disable opDollar if they
don't want it, or whether we'd rather risk 3rd party code defining opDollar as
a free function, causing conflicts with std.range.opDollar (conflicts which
wouldn't be  resolvable in the normal fashion, because $ is an operator, and
you can use an import path with it without explicitly calling opDollar). Beyond
that, I don't think that it matters much which route we take (though I do worry
somewhat that making opDollar UFCS-able would open the door to making other
operators UFCS-able, which I think would be a big mistake; but we wouldn't
actually be required to do that if we made opDollar UFCS-able), as beyond that,
the two routes seem pretty much functionally equivalent.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------