hg: lambda/lambda/langtools: 8016177: structural most specific and stuckness; ...
Maurizio Cimadamore
maurizio.cimadamore at oracle.com
Fri Aug 9 02:50:51 PDT 2013
Hi Ali,
this is not meant to be an improvement at least not one in terms of
expressiveness. There was an EG discussion last week where we went
through the overload resolution rules and there was a general feeling
that rules where too magic/complex (to be honest, this is not the first
time this comes up). This patch brings some simplification that are
mostly aimed at making the overload resolution model more uniform and
tractable.
Now, on the point that this patch goes towards removing implicit lambdas
- I think that's an unfair argument. All previously written lambda code
and all the test we had is still compiling without a glitch (despite
implicit lambdas are used almost everywhere). There were layers of
complexity in the compiler that simply weren't needed anymore as a
result of changes in the libraries that occurred in the last few months
- so I think it's a good thing that we brought the language more in
synch with the library expectations.
The argument implicit lambdas -> ambiguities is also misleading; you can
use an implicit lambda whenever the target type of that lambda is 'clear
enough' from the context. If you have several method declarations each
one accepting a SAM with different arities, that's enough to rule out
invalid candidates. But if all candidates agree on the functional
descriptor arity, I think it's actually a good thing to provide
client-site disambiguation (i.e. adding an explicit lambda parameter).
It's better for readability. It's also better because it sidesteps
important issues in the core model of overload resolution (such as
combinatorial explosions of type-checking).
Those were essentially the arguments that made all of us decide for a
simpler model. I believe some writeup of the implemented approach will
appear soon on the lambda-spec mailing list.
Thanks
Maurizio
On 09/08/13 00:29, Ali Ebrahimi wrote:
> Hi, I don't see this as an improvement. We goes towards removing
> implicit lambdas. since we have limited its application.So now
> implicit lambdas just give us ambiguity errors.
> Better would be we have clean and solid solution not remove face of
> problem.
>
>
> On Thu, Aug 8, 2013 at 6:01 PM, <maurizio.cimadamore at oracle.com
> <mailto:maurizio.cimadamore at oracle.com>> wrote:
>
> Changeset: 91c60b02c849
> Author: mcimadamore
> Date: 2013-08-08 14:30 +0100
> URL:
> http://hg.openjdk.java.net/lambda/lambda/langtools/rev/91c60b02c849
>
> 8016177: structural most specific and stuckness
> 8016178: Order of unsticking functional expressions
>
> Simplified interaction between stuck expressions and overload
> resolution. Now implicit lambdas are considered as stuck and
> cannot be used to disambiguate between multiple applicable methods
> (same holds for overloaded method reference). In such cases,
> disambiguation is only provided by the provisional applicability
> arity-based check. Added new warning (-Xlint:overloads) to flag
> potentially ambiguous declarations.
>
> ! src/share/classes/com/sun/tools/javac/code/Flags.java
> ! src/share/classes/com/sun/tools/javac/code/Lint.java
> ! src/share/classes/com/sun/tools/javac/code/Types.java
> ! src/share/classes/com/sun/tools/javac/comp/Attr.java
> ! src/share/classes/com/sun/tools/javac/comp/Check.java
> ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java
> ! src/share/classes/com/sun/tools/javac/comp/Infer.java
> ! src/share/classes/com/sun/tools/javac/comp/Resolve.java
> ! src/share/classes/com/sun/tools/javac/resources/compiler.properties
> - test/tools/javac/Diagnostics/compressed/T8012003c.java
> - test/tools/javac/Diagnostics/compressed/T8012003c.out
> - test/tools/javac/diags/examples/BadArgTypesInLambda.java
> + test/tools/javac/diags/examples/PotentiallyAmbiguousOverload.java
> ! test/tools/javac/lambda/8016177/T8016177a.java
> ! test/tools/javac/lambda/8016177/T8016177a.out
> ! test/tools/javac/lambda/8016177/T8016177c.java
> ! test/tools/javac/lambda/8016177/T8016177c.out
> ! test/tools/javac/lambda/8019480/T8019480.out
> ! test/tools/javac/lambda/BadRecovery.out
> ! test/tools/javac/lambda/ErroneousLambdaExpr.java
> + test/tools/javac/lambda/ErroneousLambdaExpr.out
> ! test/tools/javac/lambda/MethodReference22.out
> ! test/tools/javac/lambda/MethodReference23.out
> ! test/tools/javac/lambda/MethodReference41.java
> + test/tools/javac/lambda/MethodReference41.out
> ! test/tools/javac/lambda/MethodReference42.java
> + test/tools/javac/lambda/MethodReference42.out
> ! test/tools/javac/lambda/MethodReference43.java
> + test/tools/javac/lambda/MethodReference43.out
> ! test/tools/javac/lambda/MethodReference44.java
> + test/tools/javac/lambda/MethodReference44.out
> ! test/tools/javac/lambda/MethodReference46.java
> + test/tools/javac/lambda/MethodReference46.out
> ! test/tools/javac/lambda/MethodReference47.java
> ! test/tools/javac/lambda/MethodReference47.out
> ! test/tools/javac/lambda/MethodReference48.java
> + test/tools/javac/lambda/MethodReference48.out
> ! test/tools/javac/lambda/MethodReference70.out
> ! test/tools/javac/lambda/MethodReference71.out
> ! test/tools/javac/lambda/MostSpecific04.java
> + test/tools/javac/lambda/MostSpecific04.out
> ! test/tools/javac/lambda/MostSpecific05.java
> + test/tools/javac/lambda/MostSpecific05.out
> ! test/tools/javac/lambda/MostSpecific08.java
> + test/tools/javac/lambda/MostSpecific08.out
> ! test/tools/javac/lambda/TargetType01.java
> + test/tools/javac/lambda/TargetType01.out
> ! test/tools/javac/lambda/TargetType02.java
> + test/tools/javac/lambda/TargetType02.out
> ! test/tools/javac/lambda/TargetType21.java
> ! test/tools/javac/lambda/TargetType21.out
> ! test/tools/javac/lambda/TargetType24.java
> ! test/tools/javac/lambda/TargetType24.out
> ! test/tools/javac/lambda/TargetType26.out
> ! test/tools/javac/lambda/TargetType39.out
> ! test/tools/javac/lambda/TargetType43.out
> ! test/tools/javac/lambda/TargetType57.out
> ! test/tools/javac/lambda/TargetType66.java
> ! test/tools/javac/lambda/TargetType66.out
> ! test/tools/javac/lambda/mostSpecific/StructuralMostSpecificTest.java
> - test/tools/javac/lambda/typeInference/InferenceTest5.java
> ! test/tools/javac/lambda/typeInference/InferenceTest_neg1_2.out
>
>
>
More information about the lambda-dev
mailing list