Introduce a compiler option to store generic type information about a lambda expression using the Signature Attribute

[Joel Borggrén-Franck]

> On 19 jan 2015, at 16:01, Remi Forax <forax at univ-mlv.fr> wrote:
> 
> On 01/19/2015 03:39 PM, Joel Borggrén-Franck wrote:
>>> On 7 jan 2015, at 21:18, Alex Buckley <alex.buckley at oracle.com> wrote:
>>> 
>>> On 1/7/2015 7:22 AM, Timo Walther wrote:
>>>> the Java Reflection API allows to access the generic signature of
>>>> methods through the java.lang.reflect.Method#getGenericReturnType()
>>>> method. However, this is not yet supported for Lambda expressions.
>>>> 
>>>> Given the following classes:
>>>> 
>>>> class Tuple2<F0,F1> {
>>>>   F0 field0;
>>>>   F1 field1;
>>>> 
>>>>   public Tuple2(F0 f0, F1 f1) {
>>>>     this.field0 = f0;
>>>>     this.field1 = f1;
>>>>   }
>>>> }
>>>> 
>>>> interface Map<IN, OUT> {
>>>>   OUT map(IN in);
>>>> }
>>>> 
>>>> Currently, there is no solution that allows to get further type
>>>> information about expressions like:
>>>> 
>>>> Map<String, Tuple2<String, Integer>> map = (str) -> new Tuple2<>(str, 1);
>>>> System.out.println(getReturnType(map)) // can only print Tuple2 =>
>>>> information about the Tuple2's fields are always lost
>>> map is a variable, so it doesn't have a return type.
>>> 
>>> If map is a class variable or an instance variable, then Field#getGenericType should help.
>>> 
>>> Expressions (including lambda expressions) aren't generally exposed through Core Reflection. If an expression (such as a lambda expression) happens to be implemented as a method, then relying on the [generic] signature of that method is dangerous since it may change from release to release.
>>> 
>> One could argue that we should generate more attributes for synthetic methods. We did for example add annotations to bridges [1]. While we do want to it discourage depending on a specific translation strategy, I’m not sure adding Signature will make more code break once/if we change translation strategy.
> 
> The problem is not that adding a Signature will break, it's that these information will be not available
> anymore if we use a strategy based on one lambda proxy shared for several lambdas*

But isn’t this unrelated? I’m saying it might be reasonable to expect _a_ Signature for a generic method even if it is synthetic. To me it sounds like that signature will be much less specific in your prototype, but it can still exist?

cheers
/Joel