JSR 335 Lambda Specification, 0.6.2
stephan.herrmann at berlin.de
Thu Mar 21 10:48:17 PDT 2013
> This fills in many of the missing pieces in Part G, Type Inference.
Let me start by saying that this version of the spec is a big step
towards dispelling my previous concerns. After implementing most
of Part G in the Eclipse compiler I can confirm that the inference
works well as specified, but some concerns remain.
Let me illustrate the status by some test figures:
I'm using one particular chapter of our test suite that is likely
to trigger interesting inference issues.
Total number of tests: 1493
Regressions when using new type inference: 159
Of these 159 regressions the majority (111) can be directly
ascribed to the following TODOs in the spec, section 18.2.3:
"To do: define the parameterization of a class C for a type T;
define the most specific array supertype of a type T."
Could you give an ETA for a fix to these TODOs? In this case
an informal sketch would already be quite helpful.
Additionally, I could use a minor clarification on the following
items from 18.4.:
* If αi has one or more proper lower bounds, L1, ..., Lk, then Ti =
lub(L1, ..., Lk).
* Otherwise, where αi has proper upper bounds U1, ..., Uk, Ti = glb(U1,
These items don't explicitly specify how mixed proper and improper
bounds should be handled. I assume for this part to apply, *all*
bounds of the given kind must be proper bounds, right?
I first interpreted this as a filter on the set of bounds, but
that seems to yield bogus results.
More information about the lambda-spec-experts