http://d.puremagic.com/issues/show_bug.cgi?id=7177
--- Comment #33 from [email protected] 2013-03-21 14:14:50 PDT --- (In reply to comment #29) > (In reply to comment #28) > > Yeah, exactly what he said. Having yet another trait means: > > a) Don't test the trait and ignore opDollar. > > By your own definition (1. we don't check for it, and 2. you can't write > generic code with $), that is exactly what is done now. > > > b) Test the trait and fork the code even more. > > Huh? If your algorithm requires opDollar, use it. If not, then it didn't > exist before. Where is the forking? > > I looked at isRandomAccessRange. It can be true if the range is infinite, > which most likely do NOT define $. If that is the case, how can generic code > use $ simply if isRandomAccessRange is true? 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. Also, *sliceable* infinite ranges most definitely *do* define opDollar, and it is part of the requirements we'd like to add to *isSliceable*. Heck, at one point, it was argued that that should be the *only* requirement (int to $) This would be breaking change, but sliceable infinite is new concept, so it would break very little. And in this case, it would actually be a functional upgrade. Take a look at popFrontN's implementation for an example of how this would help tons. I have an open pull for chunks. Making slicing work trying to work around opDollar is a nightmare. Having the guarantee that r[1 .. $] works means we wouldn't even have to worry about whether or not r is finite. Or if it defines opDollar for that matter. > > What we are trying to do is: > > a) Not break code by adding more to the requirements. > > Wait, I thought we are adding opDollar to the requirements? 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). 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. > > b) Provide an external solution for ranges that don't define opDollar > > (because > > for a range, defining opDollar as an alias of length IS natural). > > As I previously stated, I don't have a problem with this, as long as it only > applies to ranges you define, and NOT ranges or types where it makes no sense. > > 1. opDollar is NOT equivalent to length in all cases. Therefore, making it > equivalent by default BY DEFINITION breaks existing code that purposely > defines > length and purposely omits opDollar. > 2. Adding opDollar requirements to range traits requires all existing ranges > that could define opDollar DO define opDollar. > 3. You wish to avoid immediate breakage of code that has not yet implemented > opDollar but satisfies current implementation of said traits. 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. 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. > So in other words your goal is to break existing code so other existing code > doesn't break? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
