Serialization opt-in syntax (again)
forax at univ-mlv.fr
Mon Oct 8 11:13:32 PDT 2012
On 10/08/2012 06:24 PM, Kevin Bourrillion wrote:
> I'm sorry that I'd forgotten this _ suggestion before. I like it.
We talk about _ as an identifier, not as a placeholder for a type.
Brian, I suppose that you can use '_' everywhere the inference is used,
so Array.<_>asList(2, 3) is also legal ?
> On Mon, Oct 8, 2012 at 9:20 AM, Brian Goetz <brian.goetz at oracle.com
> <mailto:brian.goetz at oracle.com>> wrote:
> still evaluate whether it's worth offering the (& Serializable)
> shorthand as well. The shorthand has benefits similar to the
> Java 7
> "diamond", though I must concede the situation only comes up a
> fraction as often.
> I agree that it is worth considering such. But, my preference
> here would be to deal with this and other sorts of verbosity in a
> single more coordinated stroke, rather than ad-hoc shorthands.
> For example, at the EG meeting we talked about reclaiming _ as a
> syntactic token. One of the motivations for having an "I don't
> want to say" token would be to support partial type inference.
> For example, we currently support diamond as all-or-nothing, but
> something finer-grained could fit right into our existing
> machinery if it had a syntax:
> new Foo<String, _>(...) // partial diamond
> Similarly, we support inferring lambda type parameters as
> all-or-nothing, but given a syntax, could do something finer-grained:
> (String s, _ y) -> ... // partial implicit lambda
> And for target-typed lambdas, we could let inference fill in what
> is known about the target type:
> (_ & Serializable) e -> true
> I think a more coordinated attack (in the future) on redundant
> type declarations would be a better choice than creating ad-hoc
> shorthands in specific situations. (Obviously we'd have to have a
> long discussion on the actual syntax.)
> Kevin Bourrillion | Java Librarian | Google, Inc. |kevinb at google.com
> <mailto:kevinb at google.com>
More information about the lambda-spec-experts