Community
Participate
Working Groups
An attempt to iteration over Sequence{1..1} performs no iteration.
Created attachment 183324 [details] Fix for singleton range The problem is that on the first iteration of a singleton range hasNext does not find curr<last so it thinks it has finished. An empty or negative range is not well-formed, so it seems sufficient to just return true for hasNext() in the starting !initialised context.
Ed, Sequence{2..1} parses well into a CollectionRange, and such a range with your patch would allow for one iteration (as would Sequence{90..-50}). I think it would be better for the check to be "return (curr < last) || (!initialized && curr == last);" so that we _only_ allow for this one iteration when the range has its "first" and "last" literals equal.
The OCL 2.2 specification is undecided about whether Sequence{2..1} is well-formed; the CollectionRangeEval::getRange recursion never terminates to yield a verdict. We can infer that since it counts up till it reaches last, that 2 is in range and 1 is not in range but all integers greater than 2 are also in range so Sequence{2..1} = Sequence{2,3,4,5,6,7,....}. I've raised an OMG issue suggesting that it could be more useful to define Sequence{3..1} = Sequence{3,2,1}. We could certainly implement this for 3.1; I'm not sure about 3.0.2 though.
Sequence{3..1} = Sequence{3,2,1} would be the best behavior, but as you mentionned, I don't think this should be done in 3.0.2. And indeed the behavior with your patch (Sequence{3..1} iterates once, on the integer "3") doesn't seem that wrong since the specification only gives examples counting "up". +1 for the current patch.
Committed to HEAD and maintenance for 3.1.0M4 and 3.0.2.
Closing all bugs resolved in Indigo.
