Serialization opt-in syntax (again)

Dan Smith daniel.smith at
Mon Oct 8 15:55:41 PDT 2012

On Oct 8, 2012, at 10:04 AM, Brian Goetz <brian.goetz at> wrote:

>> I see only two problems there:
>> * Allowing this kind of cast only on lambdas, which is ugly, but I'm OK with it.
> I don't even think that this is actually the restriction.  Yes, it affects translation of lambdas, but would also work in cases where we currently already allow intersection types:
> <T extends X&Y> foo(T t) { ... }
> ...
> Object o = makeXAndY();
> foo((X&Y) o);
> In fact, the cast to X&Y fills in a current language hole, since there's no way today to say "I *know* this is an X&Y, trust me"  We just would not be able to call foo() without knowing the name of the class.
> Admittedly this is a rare situation and has not been a significant problem so far and is clearly not the goal of this effort.  But, I do believe it provides a good example why, in the absence of an "obviously good" ad-hoc syntax, we should lean harder on extending existing concepts rather than inventing yet new ones.

There are some invariants in type-checking and inference that this may break.  Plus the complicated rules for well-formed casts would need to be revisited.  Would require some analysis...  Certainly do-able, but we can't just flip a switch.


More information about the lambda-spec-experts mailing list