Jonathan.Gibbons at Sun.COM
Tue Oct 27 17:16:05 PDT 2009
Maurizio defined these terms in emails to coin-dev round about Aug 22.
"simple" and "complex" are defined here:
I believe "full-complex" first appeared here:
I'll leave Maurizio to provide any updates on the terminology.
Neal Gafter wrote:
> Can you please define the "complex", "simple", and "full-complex"
> approaches? Which is used in the current implementation? Which approach
> can support inference in argument contexts (i.e. part occurs before overload
> resolution, part after)?
> On Mon, Oct 26, 2009 at 10:04 AM, Maurizio Cimadamore <
> Maurizio.Cimadamore at sun.com> wrote:
>> Paul Benedict wrote:
>>> Thank you for raising this point again!
>>> It was admitted the current diamond operator implementation is
>>> incomplete compared to the "complex/full" solution. It was also
>>> admitted the partial solution is not a "true subset" of the "complex"
>>> solution. With that said, I am concerned the partial solution will
>>> infer somethings in JDK 7, but a later JDK using the "complex"
>>> solution would infer differently or invalidate inferences of the
>>> partial solution. Joe, is that possible?
>> Both complex and simple are subset of full-complex. If some future
>> release will switch to full-complex the transition will be smooth (no
>> strange mismatch in types inferred by the diamond algotithm). On the
>> other hand switching from simple to complex and vice-versa will cause
More information about the coin-dev