Serialization opt-in syntax (again)
Dan Smith
daniel.smith at oracle.com
Mon Oct 8 15:55:41 PDT 2012
On Oct 8, 2012, at 10:04 AM, Brian Goetz <brian.goetz at oracle.com> 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.
—Dan
More information about the lambda-spec-experts
mailing list