MumbleCloseable

[Remi Forax]

On 06/25/2013 09:56 PM, Brian Goetz wrote:
> First, note that propagating through combinators is a nice-to-have, 
> not a requirement; if statically identifying this was never possible, 
> that would still be OK.

yes, because with no annotation at all, it's OK too.
Adding something to the type system (even if it's a pluggable 
annotation) is not like adding a method in the API.

>
> That said, a JSR-308 checker could have rules for propagating through 
> combinators like concat().  No additional versions are needed in the 
> library.

Do you suggest a whole program analysis or a way to specify first order 
like annotations ?
Like any JSR-308 checker, I will believe that it "could have rules that" 
when I will see it properly specified.

Rémi

>
>
> On 6/25/2013 3:52 PM, Remi Forax wrote:
>> On 06/25/2013 06:41 PM, Brian Goetz wrote:
>>> Following along this line, some structural choices for hint
>>> annotations.  I think the key hint is "definitely holds", though we
>>> might also want "definitely does not hold".
>>>
>>> interface MayHoldCloseableResource extends AutoCloseable {
>>>     void close();  // no exceptions
>>>
>>>     @interface DefinitelyHolds { }
>>> }
>>>
>>> ...
>>>
>>> package java.nio;
>>> class Files {
>>>     ...
>>>     @MayHoldCloseableResource.DefinitelyHolds
>>>     Stream<String> lines(Path p) { ... }
>>> }
>>>
>>> or...
>>>
>>> interface MayHoldCloseableResource extends AutoCloseable {
>>>     void close();  // no exceptions
>>>
>>>     enum HoldHint { YES, NO }
>>>     @interface Hint {
>>>         HoldHint value();
>>>     }
>>> }
>>>
>>> ...
>>>
>>> package java.nio;
>>> class Files {
>>>     ...
>>>     @MayHoldCloseableResource.Hint(YES)
>>>     Stream<String> lines(Path p) { ... }
>>> }
>>
>> Could you provide an example that use concat() to concatenate two
>> streams in the two cases ?
>> I don't understand how it can works without providing 4 (may be 3)
>> versions of concat (hold/doesn't hold for each parameter).
>>
>> Rémi
>>
>>>
>>>
>>>
>>>
>>> On 6/25/2013 11:37 AM, Brian Goetz wrote:
>>>> Actually,
>>>>
>>>> MayHoldCloseableResource
>>>>
>>>> seems not too bad.  It is a tad wordy, but relatively few people will
>>>> have to type it, and reading it is pretty clear -- this object may 
>>>> hold
>>>> a closeable resource.
>>>>
>>>> On 6/25/2013 11:14 AM, Brian Goetz wrote:
>>>>>> These together provide something better than any other related
>>>>>> schemes I know. I think that if we cam up with stunningly
>>>>>> good names for these, the plan would be completely uncontroversial.
>>>>>
>>>>> MayHoldResource
>>>>> HoldsResource
>>>>> MayRequireClosing
>>>>> ...
>>