[Feature] union type

[b1ek]

Is your feature request related to a problem? Please describe.
this type definition is valid in typescript:

let thing: string | null

i'd love to be able to do the same in amber

Describe the solution you'd like

let thing: String | Null
thing = "abc"
thing = null
if thing is Text {
    echo "its text!" // never executed
}

Describe alternatives you've considered
Generic types, but.. meh

Additional context
Add any other context or screenshots about the feature request here.

[hdwalters]

let thing: string | null

It depends on whether you want (i) any combination of types, or (ii) just nullable/optional types. I can't see much use for the former, because the operations you can perform on multiple types are limited, basically just + for numbers, strings and arrays.

If the latter, you might consider allowing a question mark at the end of the type, like C# and Kotlin; so Num?, Text?, [Text]? etc. You may even want [Text?]?. I suspect this would be easier to parse, too.

[b1ek]

let thing: string | null

It depends on whether you want (i) any combination of types, or (ii) just nullable/optional types. I can't see much use for the former, because the operations you can perform on multiple types are limited, basically just + for numbers, strings and arrays.

If the latter, you might consider allowing a question mark at the end of the type, like C# and Kotlin; so Num?, Text?, [Text]? etc. You may even want [Text?]?. I suspect this would be easier to parse, too.

any combination of types. question mark after type is already taken, it means that it is fallible

[b1ek]

okay so there has been some controversy about how union types should be equal to other types and each other. i think we should do it like this:

1. a union type is equal only to another union that has the exact same types under it, no matter the order
2. a union type is converted to a singular type with an if union_variable is Type statement, only inside that if block

@Ph0enixKM @Mte90 @mks-h

[mks-h]

Here's how I see this:

The union type must function just like the Failable and Generic Array types in #472. This means that:

1. Arguments of a type that is a subset of the parameter's type must be allowed.
2. The return statement must allow value to be returned if its type is a subset of the defined return type.
3. The is operator must continue to check the actual type of the value.

Additionally, the union type must not allow failable types as part of the union. The union type itself must be failable, instead. Otherwise it won't come together with the error handling logic.

The groundwork for the subset logic is already laid out in #472, which I intend to merge before this one. Then you will have to put your union logic on top of it.

[b1ek]

how would it work that the whole union is failable, from the syntax point of view? do we just assert that all types in union are either failable or non failable? or something like (Text | Null)??

[b1ek]

Arguments of a type that is a subset of the parameter's type must be allowed

i assume that you mean in the function arguments, right?

[b1ek]

i think that any singular type can be automatically converted to union with the same type in there Text ==> Text | Null, but not in reverse Text | Null ==> Text - that would require an if var is Type check

[mks-h]

I'm not exactly sure how the syntax should look, but it should probably be (Text | Num)? The extra parentheses are kind of a hassle, but I don't think we can do anything about it. That is, unless we want to change the failable syntax to fun whatever()?: Text, ():? Text, or (): ?Text.

i assume that you mean in the function arguments, right?

Yes.

automatically converted

We must not convert any types. The compiler has to keep track of the actual types, so that the is type checking works. Instead of converting a type, we simply check if it is allowed to pass where another (wider/superset) type was expected.

[b1ek]

we could also change failables to Failable<T>

[Ph0enixKM]

The [Text?]? makes no sense as of right now. Let's later later add parentheses syntax so that it can parse this case:

fun foo(): (Text | Num)? {}

because Text | Num? looks as if the Num was a failable type. And so this should be forbidden and compiler should suggest adding parentheses around the union type expression when function is failable.

[b1ek]

i have a feeling that failable types should not be implemented as types, but rather as a function modifier, like:

pub failable function get_data(): Text {
    return $curl https://data.com$?
}

[mks-h]

we could also change failables to Failable

This is a whole word more verbose than the (T)?

pub failable function get_data(): Text

That's also quite verbose.

[Ph0enixKM]

One idea is that we could move the ? to the function name:

fun foo?(): Text 

[mks-h]

Question mark right after a word makes it a bit funny to read, lol. Reads like a question.

[b1ek]

... more verbose ...

... quite verbose

so what is your point being?

[mks-h]

The point is that none of them is any better than the (T | U)? syntax, in terms of being succinct (which is the issue we try to solve). So far, the only better options I see are:

1. fun name()?: T | U
2. fun name?(): T | U by @Ph0enixKM

The failable modifier before fun keyword is not the worst idea, but I don't like to have a lot of keywords before fun.

[b1ek]

we should discuss failable types further in #478