Some Classes with a public void close() don't implement AutoCloseable

[Eric Vergnaud]

But without changing the existing behavior, it could be enhanced…

In en experimental language called Prompto, there is a concept of Resource which must implement open() and close().
The runtime calls open() and close() as part of the TWR equivalent construct.

This enables elegant explicit constructs:

try(res = new MyResource("some locator")) {
	l1 = readLine(res);
	l2 = readLine(res);
	...
}

and implicit ones:

lines = readAll(new MyResource("some locator"))

(readLine and readAll are Prompto builtins which only accept Resouce as parameters)

you can only instantiate a resource within an explicit TWR header or and implicit TWR construct.
(so: new MyResource() outside a TWR header or implicit TWR throws a syntax error)

this provides much better guarantees than AutoCloseable

How about adding something like:

public interface AutoOpenable<T extends AutoCloseable> {
	T open();
}

If TWR accepted both AutoOpenable and AutoCloseable, then there would be no break the current behavior, but it would become possible to implement the now desired behavior?
(appreciate this would require some additional thinking for existing AutoCloseable classes)

Eric


> Le 18 avr. 2020 à 23:31, Brian Goetz <brian.goetz at oracle.com> a écrit :
> 
>> I think these issues were discussed and are the reason why
>> try-with-resources requires the introduction of a new variable, to
>> make clearer that there is no ownership in the evaluation of the
>> expression.
>> 
>> I guess this probably was onl partially successful, due to the
>> wrapping of streams and code like this:
> 
> These discussions illustrate the tensions inherent in proposing “pain reduction” features like TWR.  On the one hand, TWR addresses a real pain point; on the other, it was knowingly limited.  The arguments pro and con write themselves: “this is addressing a real problem”, “don’t let the perfect be the enemy of the good”, etc; while these might in fact be compelling arguments in any given situation, the fact remains that, should these features succeed in their essential purpose, their limitations will become immediately constraining.  (Similar complaints could be made of the for-each loop, in that it offers no way to access the index (for array loops) or iterator (for Iterable loops.)  And the limitations were known at the time the feature was being proposed.
> 
> So here we are, now trying to go back and fix something that was considered and rejected at the time, because we have since discovered that we were wrong when we said “we’d be happy if we could just solve X.”   And fixing it is harder now, because we have to work within the constraints of a feature that was deliberately designed to be limited (whereas, when the feature was being designed, more things were possible.)  
> 
> Without commenting on the merits of the current round of proposals, let me just remind everyone that nailing epicyclical bags on the side of an incomplete feature will not make it complete….