On 2012-04-04 19:09, Jonathan M Davis wrote:
That might work, but it does make it so that ".." has very different meanings in different contexts, and I don't know that it really buys us much. iota already does them same thing (and with more functionality), just without the syntactic sugar. Also, we've had enough issues with moving AA's into druntime, that I don't know how great an idea this sort of thing would be (though it should be much simpler). It would certainly make some folks (e.g. Bearophile) happy though.
Yeah, we don't have to stop any releases for this. It's one of those features in the language that is not very consistent and sometimes that just a bit annoying.
This could then be taken advantage of in other parts of the language: class A { int opSlice (range r); // new syntax int opSlice (size_t start, size_t end); // old syntax } I think this would be completely backwards compatible as well.Except that opSlice already works with "..". What would this buy you?
Nothing, but that's how the language could have looked like if a first class range type had been added to the language a long time ago.
It doesn't make sense to pass opSlice a range normally. Why treat this proposed "range" type any differently from any other range? This functionality already exists with the second declaration there. If we added a range type like this, I'd be inclined to make it __range or somesuch and not ever have its name used explicitly anywhere. It would basically just be syntactic sugar for iota (though it wouldnt' use iota specifically). I don't know what else you would be looking to get out of using its type specifically anywhere. That's not general done with other range types.
In this case "range" is just a start and end of a list of numbers, maybe "range" is not a good name IT conflicts with the concept of ranges.
No, instead we use templates like mad. -- /Jacob Carlborg
