On Fri, 23 Apr 2021 at 17:08, Brian Goetz <brian.go...@oracle.com> wrote:
> This has come up before. For example, during an early iteration of the
> Stream design, before parallelism entered the picture. The first
> scrawled-on-a-napkin prototype for streams was based on Iterator, and it took
> about a minute to realize that we could do a much better job if we had a
> slightly broader interface to work with, essentially Iterator+Sized.
>
> When you pull on this string, you end up with a lot of new interfaces, such
> as SizedIterator, SizedIterable, etc, in part because ... we have no
> intersection types. Having lots of fine-grained interfaces for "has X" and
> "has Y" is nice from a "bucket of lego bricks" library-design perspective,
> but when the user goes to express "I need an aggregate that has sizes,
> iterators, and encounter order", you end up with code like:
>
> <T, X extends Iterable<T>&Sized> void foo(X x) { ... }
>
> and then you run into the wall of "but I can only use intersection types in
> these places in the language." The idiom of having fine-grained mix-in-ish
> interfaces really wants a language with intersection types.
>
> Additionally, I am having a hard time imagining how Sized would be usable by
> a client; no method will *take* a Sized (it's just not broad enough), and I
> can't immediately imagine what would even *return* a Sized. If the type is
> not suitable for use by clients, then it serves only to organize the library
> itself, and that's a weaker motivation.
>
> Is there a compelling example of where this would be used by clients?
Here are some examples:
https://stackoverflow.com/questions/10988634/java-global-isempty-method
https://github.com/OpenGamma/Strata/blob/main/modules/collect/src/main/java/com/opengamma/strata/collect/ArgChecker.java#L404
ie. the ability to spot an "empty" object, or ensure input is
non-empty. Use cases are generally in low-level/framework code like
this, where the actual input data type is not known.
Stephen
