http://d.puremagic.com/issues/show_bug.cgi?id=7177
--- Comment #13 from [email protected] 2013-03-21 07:18:13 PDT --- (In reply to comment #12) > If we don't make it so that length automatically aliases to opDollar if > opDollar isn't already defined, then almost every single finite random-access > range ever will have to manually alias length to opDollar, and we'll never be > able to require that ranges with slicing define opDollar, because it would > break too much code if we did. > > I see no downside to this and huge problems if we don't do this. This is the > key to being able to rely on opDollar existing for ranges types that should > define it. They point of dissension here (as I see it), is that you are saying that a range must define opDollar one way or another, whereas I think all we need is for r[$ - 1]/r[0 .. $] to work. My proposal would not prevent isSliceable for checking this, any less than isInputRange says that slices are ranges. Slices have front defined externally, which allows us to use them as ranges all over the place. I don't see why we can't use the same approach with ranges and opDollar. I agree it is a HUGE boost to be able to rely on "r[0 .. $]" being legal. I just find it is kind of iffy to rely on the compiler for that... But just to be clear, I prefer this than no solution. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
