为什么Iterable不提供stream()和parallelStream()方法？

我想知道为什么Iterable接口不提供stream() and parallelStream()方法。考虑下面的类：

public class Hand implements Iterable<Card> {
    private final List<Card> list = new ArrayList<>();
    private final int capacity;

    //...

    @Override
    public Iterator<Card> iterator() {
        return list.iterator();
    }
}

它是一个实现Hand因为您在玩集换式卡牌游戏时手上可以有牌。

本质上它包裹了一个List<Card>，确保最大容量并提供一些其他有用的功能。最好直接将其实现为List<Card>.

现在，为了方便起见，我认为最好实施Iterable<Card>，这样如果您想循环它，您可以使用增强的 for 循环。 （我的Hand类还提供了一个get(int index)方法，因此Iterable<Card>我认为是有道理的。）

The Iterable接口提供以下内容（省略 javadoc）：

public interface Iterable<T> {
    Iterator<T> iterator();

    default void forEach(Consumer<? super T> action) {
        Objects.requireNonNull(action);
        for (T t : this) {
            action.accept(t);
        }
    }

    default Spliterator<T> spliterator() {
        return Spliterators.spliteratorUnknownSize(iterator(), 0);
    }
}

现在您可以通过以下方式获取流：

Stream<Hand> stream = StreamSupport.stream(hand.spliterator(), false);

那么进入真正的问题：

• 为什么Iterable<T>不提供默认方法来实现stream() and parallelStream()，我没有看到任何东西会使这成为不可能或不需要的？

我发现的一个相关问题如下：为什么 Stream 不实现 Iterable？
奇怪的是，这表明它以相反的方式做这件事。

这并不是一个遗漏；而是一个事实。 2013年6月对EG清单进行了详细讨论。

专家组的最终讨论源于这个线程.

虽然这似乎是“显而易见的”（甚至对于专家组来说也是如此）stream()似乎有道理Iterable，事实是Iterable如此笼统成了一个问题，因为明显的签名：

Stream<T> stream()

并不总是你想要的。曾经的一些事Iterable<Integer>宁愿让他们的流方法返回一个IntStream， 例如。但把stream()层次结构如此之高的方法将使这成为不可能。因此，我们让制作变得非常容易Stream从一个Iterable，通过提供spliterator()方法。实施stream() in Collection只是：

default Stream<E> stream() {
    return StreamSupport.stream(spliterator(), false);
}

任何客户端都可以从Iterable with:

Stream s = StreamSupport.stream(iter.spliterator(), false);

最后我们得出的结论是添加stream() to Iterable将是一个错误。