http://d.puremagic.com/issues/show_bug.cgi?id=7177
--- Comment #53 from Jonathan M Davis <[email protected]> 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: -------
