Serialization opt-in syntax (again)

Brian Goetz brian.goetz at
Mon Oct 8 09:04:16 PDT 2012

> 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.

More information about the lambda-spec-experts mailing list