http://d.puremagic.com/issues/show_bug.cgi?id=7177
--- Comment #56 from Kenji Hara <[email protected]> 2013-03-31 10:21:20 PDT --- (In reply to comment #55) > @Kenji: I'm a bit unclear on your view on this. You mention you'd prefer a > library solution but your pull request seems to go for a in-compiler solution. As Steven already mentioned in comment#14, automatically forwarding from $ to 'length' would break user-defined containers. The fact clearly represents that we cannot always regard $ as "length". Indeed, it is true in built-in arrays and range concept, but isn't true in associative arrays and some user-defined containers. So I think that this enhancement has a bias toward range concept. And, as far as possible, compiler should be a neutral. In other words, this is just reasonable for std.range users. Most of D programmers would use std.range, but not all. > There is no intent to cover infinite forward ranges with default behavior. > Again, the primary goal here should be, I think, to make code defining casual > ranges easy and boilerplate-free. Infinite ranges or ranges that don't define > length yet want to define slicing through to the end are comparatively rare. > It > is reasonable to request people defining those to define opDollar > appropriately. I don't mention that infinite range _should_ have r[n..$], rather mention that it is possible. > If we go for a library solution, we should define opDollar in object.d so it's > available by default. It should look something like this (in the 1-dimensional > case): > > auto ref opDollar(R)(auto ref R r) if (is(typeof(r.length))) { > return r.length; > } This is bad. druntime should not have things for range concept. It is a job of std.range. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
