Syntax for union types

[Yuh-Ruey Chen]

Lars Hansen wrote:
> > Not only is (int | string) more intuitive than (int, string), 
> > the (int, string) syntax can be reserved for another yet-unknown
> purpose.
>
> Intuition tends to be personal, and the other argument can be turned on
> its head (why wouldn't I want to use "int | string" for something else
> in the future?).  Since "|" is bitwise or, "||" would have been better,
> but that has yet other connotations.
>   

Well, I didn't draw that intuitiveness primarily from ES3 operators. It
comes from regexes (which are already in the langauge) and common
grammar notation (which are well-known to CS majors), which all tend to
use "|" as the "or" operator.

> > Along the same lines, I find the syntax for constraining list 
> > types to be unintuitive. [int] is very different from [int, 
> > string], and [int, string] is very different from (int, 
> > string). Perhaps that (int, string) can describe the tuple 
> > type. And [int | string] could be syntactic sugar for [(int | 
> > string)]. The usage of "|" improves readability in that 
> > there's no way to confuse a union type with a tuple type.
>
> This has been discussed at considerable length, and we've concluded that
> the current solution represents a workable compromise.
>   

A compromise between what? I'm not aware of any existing implementation
(besides the RI) that uses union types. I'm also unaware of any
published discussion concerning the syntax of union types (didn't find
any in the wiki).

> (More interesting open questions about the language are whether generic
> functions ought to be available on instances or discriminating on
> structural types, or whether packages ought to be sealable for security,
> or whether ES4 precludes the use of current ES3 AOP patterns and how
> that might be solved.  Among other things.)
>
> --lars
>   

By "generic functions ought to be available on instances", do you mean
non-global generic methods? TBH, I consider generic functions a bit of
an odd fuck in ES4, because of its many restrictions compared to normal
functions (see the "non-features, future directions, etc." section on
the generic functions proposal).

-Yuh-Ruey Chen