Michel Fortin: > In the D/Objective-C bridge, I've defined the NSRange struct (a Cocoa > type representing an integer interval) so it can be created by typing > NSRange[start..end] in adition to the traditional NSMakeRange(start, > length). It's better than nothing, but even better would be the ability > to omit NSRange[] entirely.
In my dlibs I have xrange/range, but I am also looking for something that the compiler can recognize and optimize away better. > As for strides, why not just (a..b ~ c..d) for joining two ranges and > ~(x..y) for everything outside x..y ? Weeks ago I have strongly suggested Alex to add support for ~ to join any kind of lazy/eager iterable to any other lazy/eager iterable (if the types of the items they yield are equal or castable). I have defined xchain and the Chainable mixin in dlibs for this very useful purpose. > The only downside is that it may confuse people who are accustomed to > the GCC extension with define an inclusive interval this way: Too bad for them. > Perhaps we could make 3 dots mean an inclusive interval (including the > second value in the interval), and 2 dots an exclusive one (excluding > the second value). Ruby follows your idea, but for the eye it's easy to miss the extra dot, so I don't like this much (but I think an optional stride syntax may be useful, especially if such stride can be negative too. You can also perform a little optimization if the stride is known at compile time, as it often happens). Bye, bearophile