MumbleCloseable

[Paul Sandoz]

What about the following:

  Stream s = Files.lines(path));
  s = s.filter(goGetMeAPredicate()); // Exception thrown
  return s.collect(toList());
  ...
  Predicate goGetMeAPredicate() {
    throw new RuntimeException();
  }

There may be other stuff being performed in conjunction with the stream holding a GCR stuff.

Are you proposing that GCR state should be lazily initialized when the terminal operation commences with appropriate management of that state in the AutoCloseable? That would also result in errors at a distance.

Paul.

On Jun 25, 2013, at 9:30 AM, Remi Forax <forax at univ-mlv.fr> wrote:
> As someone said one the lambda-dev mailing list, there is no TWR in C# because close is called at the end of the for-each instruction.
> Why do you want user to care about releasing resources manually if this can be done automatically ?
> 
> A Stream is an abstraction over a loopy thing, so like in C#, the Stream should call close at the end if the source is an AutoCloseable.
> Thus either the Spliterator takes care of the resource, but conceptually a Spliterator is more an abstraction over a traversal algorithm
> or the Stream takes care of the resource.
> Thus the solution is easy, instead of constructing a Stream with 2 parameters, the supplier of spliterator and the characteristics,
> we need a third parameter, an AutoCloseable that may be null and in the implementation of all terminal methods of Stream,
> we have to enclose the 'loop' over the spliterator inside a TWR.
> 
> Sometimes the simple solution is the best one.
> Rémi
> 
> 
> 
> 
>