Well, I expect it to be an optional<S> only as well, but I'm not sure. Normally this kind of redundancy gets collapsed away (and there is no reason for it to be an optional<optional<S>>.)
Ok, I looked: you're right, but I consider this to be a bug. This will be fixed in the next release, then.
Oh right. I had considered it desired behaviour. The grammar spec is
(start || (':' >> -start))
and not
(start || (':' >> start))
I would expect optional<S> for both only in the latter case.
In the former I am deliberately allowing the specifier to the right of the colon to be omitted -- within the already optional right-hand-side of the sequential-or. This allows for input such as
(1) $x // $x (assume it references a sequence) (2) $x[7] // element 7 of $x (3) $x[7:] // a slice of $x beginning at element 7 (4) $x[:7] // a slice of $x up to element 7 (5) $x[2:7] // a slice of $x beginning at 2 ending at 7 (6) $x[:] // equivalent to $x (unspecified bounds)
In the action function, wrt to right-hand-side of the sequential-or, I need to determine: a) whether a range specifier has been provided at all (given by (bool) at_c<1>(access_spec)) b) whether the range specifier includes an explicit bound (given by (bool) *at_c<1>(access_spec))
The left-hand-side of the sequential-or is either an (optional) 'range_begin' index if a range specifier is given or a lone 'index' specifier if no range specifier is given.
If the two optionals on the right-hand-side were collapsed would I not lose the ability to distinguish between (2) and (3)?
Yes, you're right, doh! Sorry for the noise. Regards Hartmut ------------------- Meet me at BoostCon http://boostcon.com