http://d.puremagic.com/issues/show_bug.cgi?id=7177
--- Comment #29 from Steven Schveighoffer <[email protected]> 2013-03-21 12:47:14 PDT --- (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 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? > 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. 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: -------
