Serialization opt-in syntax (again)
Brian Goetz
brian.goetz at oracle.com
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