subrange::advance(n) is specified to call ranges::advance(begin_, n, end_) in both StoreSize and !StoreSize cases ([range.subrange.access]/9). Unfortunately, ranges::advance(begin_, n, end_) has undefined behavior when n < 0 unless [end_, begin_) denotes a valid range ([range.iter.op.advance]/5). This would all be perfectly fine — the UB is exposed to the caller via effects-equivalent-to — were it not the design intent that subrange::advance(-n) be usable to reverse the effects of subrange::advance(n) when the subrange has a bidirectional iterator type. That is, however, clearly the design intent: subrange::prev(), for example, is equivalent to subrange::advance(-1).