http://d.puremagic.com/issues/show_bug.cgi?id=7177
--- Comment #36 from Steven Schveighoffer <[email protected]> 2013-03-21 19:42:41 PDT --- (In reply to comment #33) > What's your point? isRandomAccessRange doesn't require length either. Does > that > mean code that tests isRandomAccessRange can't use length? That's why we > usually test RA+hasLength. However, once you have an RA range that defines > length, it would make little sense for r[$ - 1] to not function. And it probably would function. You don't need a trait to write code that expects $ to work. And even if $ DID work, it may not work the way you expect, that is, length and $ may not be equivalent. In other words, it's impossible to write a trait that says "$ must be equivalent to length." It is OK with me, however, if you want to say that a RA range with hasLength requires $ to function as length. I just don't want the compiler to assume that $ means length for all types. > No. What we want is that if a range is finite and random access, then writing > "r[$ - 1]" should be legal. And "r[0 .. $]" should be legal for sliceables > (regardless of length). r[0..$] is equivalent to r[], there is no need to require it. > That is the goal. We are discussing the how. One idea is to change the trait. > What we'd want is a functionality that would allow us to do this without > breaking existing code. Changing the trait will break existing code, making the assumption will break existing code. There is nothing that can be done I can think of that wouldn't break existing code. So if you have to break existing code, break phobos code that can be fixed in the same commit! > Ranges is a phobos concept we can define ourselves as we so wish. If you > decide > to adhere to the interface, but do non-sense with it, that becomes _your_ > problem. In regards to *ranges*, if one defines length, but not opDollar, then > it would make *0* sense for r[0 .. $] to not mean r[0 .. r.length]. If you > have > a "ranges [...] where it makes no sense", then it is the range that makes no > sense. That is fine, as I've already said. If you want to change the trait, go right ahead! > The range may also decide to implement it's own opDollar if it so wishes. But > if it doesn't, we can do it. We do this with UFCS all the time. I don't see > why > we can't do it for opDollar to, either via a global function, or compiler > help. Doing it in the compiler is not correct, the compiler shouldn't care what opDollar means. Otherwise, it should just make $ mean length. Ranges are a phobos concept. If you want to define it for isRandomAccessRange + hasLength only, I think that is fair too (I'm assuming here we can change the compiler to allow adding opDollar using UFCS). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
