On Wed, 5 Oct 2022 15:15:05 GMT, Viktor Klang <d...@openjdk.org> wrote:
>> src/java.base/share/classes/java/util/SequencedCollection.java line 93: >> >>> 91: * underlying collection. Changes to the underlying collection >>> might or might not be visible >>> 92: * in this reversed view, depending upon the implementation. >>> 93: * >> >> @stuart-marks Perhaps an opportunity to spec it so that x == >> x.reversed().reversed() (i.e. unwrap on double-reverse)? > > @stuart-marks What are examples of cases where it wouldn't be reasonable: > https://github.com/openjdk/jdk/pull/7387/files#diff-2b261a88d9ed30893d24186a36ef500d284d82e8f345591fc6c44ed5ae15da4fR161 > ? I had to uncomment that line to figure out what broke. :-) Turns out `TreeSet.reversed().reversed()` doesn't return the original TreeSet. This is because `descendingSet().descendingSet()` doesn't unwrap, and neither does TreeMap's `descendingMap().descendingMap()`. I don't know what this wasn't done in the first place. Nonetheless, since unwrapping isn't done in the underlying implementation, it doesn't seem reasonable for the specification to require it be done. Furthermore this enables `reversed()` to be implemented as a default method that simply delegates to the respective `descending*()` method. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1012410605
