A syntax option (function types versus arrays)

Joshua Bloch jjb at google.com
Mon Mar 1 18:01:40 PST 2010


Neal,

I don't find this argument convincing. As I understand it, you're saying
that function types and disjunction types will have the same level of
runtime support as generics. So they should have the same level of
expressiveness as well: it should be possible to describe, but not create
(except implicitly for varargs) arrays of these types.

   Josh

On Mon, Mar 1, 2010 at 5:55 PM, Neal Gafter <neal at gafter.com> wrote:

> On Mon, Mar 1, 2010 at 4:58 PM, Joshua Bloch <jjb at google.com> wrote:
> > Why do you say we won't be able to express arrays of disjunction types?
> Is
> > there some fundamental reason it's not possible?
>
> No, we can technically add support for anything we want, but if the
> syntax can't be used safely in the language, it doesn't make much
> sense.  We'd really have to go out of our way to make up a syntax that
> is more awkward just to make sure we can express something that we
> cannot implement.  What you're proposing is a false orthogonality.  I
> understand what 308 did by adding support for annotating types in only
> some (but not all) places in the language for no particular technical
> reasons but absence of compelling use cases, but in this case we have
> sound technical reasons as well.  (If it wasn't clear, disjunction
> types are not reifiable).
>
> > If so, then yes, they'd be
> > second-class citizens (if we decided to support them). But that's no
> reason
> > to turn function types into second class citizens when we have a choice
> in
> > the matter.
>
> Whether the syntax makes it obvious or not, function types would be
> second-class citizens in precisely the way you're complaining about:
> there's no correct way to make arrays of them.  We'd not be doing any
> favors by pretending otherwise in the syntax.
>


More information about the lambda-dev mailing list