> De: "Brian Goetz" <brian.go...@oracle.com> > À: "Remi Forax" <fo...@univ-mlv.fr> > Cc: "Stuart Marks" <sma...@openjdk.java.net>, "core-libs-dev" > <core-libs-dev@openjdk.java.net> > Envoyé: Mardi 3 Novembre 2020 20:54:57 > Objet: Re: RFR: 8180352: Add Stream.toList() method
>>> There is no value in making users remember which stream methods are >>> null-hostile and which are null-tolerant; this is just more accidental >>> complexity. >> I think that ship has sailed a long ago. >> Some collectors are null hostile, some are not. >> You can make a point that a Collector is technically not the Stream API per >> se. > Yes, and this is no mere "technical argument". A Collector is a collection of > behaviors, governed by its own spec. The behaviors passed to stream > operations, > whether they be lambdas passed by the user (`.map(x -> x.hopeXIsntNull())`) or > collector objects or comparators, are under the control of the user, and it is > the user's responsibility to pass behaviors which are compatible with the data > domain -- which the user knows and the streams implementation cannot know. >> Because of that, i don't think we even have the choice of the semantics for >> Stream.toList(), it has to be the same as >> stream.collect(Collectors.toList()). > This doesn't remotely follow. (And, if it did, I would likely not even support > this RFE.) It seems you had an issue when replying to my mail, there is a paragraph before "Because" > Let's take a step back, > if we introduce a method toList() on Stream it will be used a lot, i mean > really > a lot, to the point where people will change the code from > stream.collect(Collectors.toList()) to use stream.toList() instead. > The spec of Collectors::toList was crafted to disavow pretty much anything > other > than List-hood, in part in anticipation of this addition. >> But it can not be immutable too, for the same reason. > Nope. The spec of toList() very clearly says: no guarantees as to the type, > mutability, serializability, etc etc of the returned list. That doesn't mean > that every method returning a List added to the JDK after Collectors::toList > must similarly disavow all such guarantees. > (In fact, we would be entirely justified to change the behavior of > Collectors::toList tomorrow, to match the proposed Stream::toList; the spec > was > crafted to preserve this option. We probably won't, because there are too many > programmers who refuse to read the specification, and have baked in the > assumption that it returns an ArrayList, and this would likely just be picking > a fight for little good reason, regardless of who is right.) I don't understand your argument. You know that you can not change the implementation of Collectors.toList(), and you also know that if there is a method Stream.toList(), people will replace the calls to .collect(Collectors.toList()) by a call to Stream.toList() for the very same reason but you want the semantics of Stream.toList() to be different from the semantics of Collectors.toList(). Rémi
