inference of throws type parameters in SAMs

[Maurizio Cimadamore]

On 31/10/12 17:04, Remi Forax wrote:
> On 10/31/2012 03:53 PM, Dan Smith wrote:
>> This is on the radar for inference.  As you suggest, we would probably just choose RuntimeException in certain scenarios rather than using the upper bound.
>>
>> We have toyed with some more ambitious ideas for handling exceptions in lambda bodies, but those won't be part of Java 8.
>>
>> —Dan
> yes, and my fear is that if we choose something different than Object
> now (like RuntimeException)
> we will not be able to change the inference algorithm in Java 9.
> At least with Object as default, we know that currently the inference
> fails so
> we can provide a better one without creating incompatibilities.
I think Object is never a problem - for this kind of issues to show up, 
the inference variable must appear in the throws clause, which means it 
should be at least <: Throwable.

Maurizio
>
> Rémi
>
>> On Oct 30, 2012, at 10:18 AM, Peter Levart <peter.levart at gmail.com> wrote:
>>
>>> Hi all,
>>>
>>> I know this has been discussed before, but a long time has passed and
>>> various inference algorithms have been tried in the meanwhile. So I
>>> would like to ask whether current state is final. For example if I have
>>> a functional interface like the following:
>>>
>>> public interface ThrowingFactory<T, E extends Throwable> {
>>>       T make() throws E;
>>> }
>>>
>>>
>>> And a "hypothetical" method:
>>>
>>> public interface Stream<T> {
>>>       <E extends Throwable> T findFirstOrElse(ThrowingFactory<T, E>
>>> other) throws E;
>>> }
>>>
>>>
>>> Then the following program compiles OK:
>>>
>>>       public static void main(String... args) throws IOException
>>>       {
>>>           Stream<String> stream = null;
>>>
>>>           String first = stream.findFirstOrElse(() -> {throw new
>>> IOException();});
>>>       }
>>>
>>>
>>> Which indicates that the inference algorithm does it's job correctly.
>>> But the following program:
>>>
>>>       public static void main(String... args)
>>>       {
>>>           MyStream<String> stream = null;
>>>
>>>           String first = stream.findFirstOrElse(() -> "NO VALUE");
>>>       }
>>>
>>>
>>> Triggers the compilation failure:
>>>
>>> error: unreported exception Throwable; must be caught or declared to be
>>> thrown
>>>           String first = stream.findFirstOrElse(() -> "NO VALUE");
>>>
>>>
>>> Regards, Peter
>>>
>>>
>>>
>>> P.S. If this worked, the controversial TypeThatMustNotBeNamed<T> which
>>> is used as return type of 3 Stream methods could be replaced with 3*3=9
>>> Stream methods that would more or less fit the main purpose of being
>>> fluent. For example, current Stream.findFirst() would expand to:
>>>
>>> public interface Stream<T> {
>>>       T findFirst() throws NoSuchElementException;
>>>       T findFirstOrElse(T other);
>>>       <E extends Throwable> T findFirstOrElse(ThrowingFactory<T, E>
>>> other) throws E;
>>> }
>>>
>>> Is this to much methods?
>>>
>>>
>>>
>