getOrElseUpdate
to get(key).getOrElse(put(key, default))
, and my understanding of the point of getOrElseUpdate
is that it's supposed to be faster than that (due to only having to find the entry once)
knownSize
to be O(1)
, it also must be very fast
knownSize
is always O(1)
in the library so far. I would say O(log n)
is more like O(1)
than like O(n)
(in the sense that O(log n)^2
is less than O(n)
), so if it happened somehow to take O(log n)
time to compute knownSize
it probably should be computed instead of returning -1
.
IterableOnce
or an Iterator
without looping myself? Wouldn't last
/lastOption
make sense for them (I know the other right-oriented variants takeRight
/dropRight
were removed earlier from the strawman as they would require buffering, but last
/lastOption
would only need a buffer of size one)?
ListBuffer.from(iterableOnce).lastOption
reduce
and fold
also work
List
for instance, Seq
wants concat
to mean appendedAll
, but there's a StrictOptimizedIterableOps#concat
that gets mixed in later..
concat
enate" implies an order, but the paint's dry on that shed, I'm sure)