[dart-misc] NNBD proposal makes more sense with Union Types

[Cristian Garcia]

Look at issue #11 <https://github.com/chalin/DEP-non-null/issues/11> I
posted on github. I post the text again here:

The proposal states

That is, generally speaking, an unadorned class type T will represent the
non-null type consisting (strictly) of instances of T. When needed, the
meta type annotation ? can be used; ?T denotes the nullable type derived
from T, consisting of values from T or null.

Doesn't the statement

T or null

practically imply/begs for *union types*? Ceylon does this beautifully
where String? is short hand for String | Null. Dart could integrate the
same approach now that its making breaking changes.

[Filipe Morgado]

+1000

Not that I want to hinder the NNBD proposal, which I find great and holds
the highest value.

But, I agree with Cristian.
Fundamentally, NNBD and union types solve the same problem, with NNBD being
a "subset" of union types.

It would maybe mean a little more work ... once ... than "in two (possibly)
breaking changes" (as I said in another thread).

If Ceylon had its own VM (and was backed up by a stronger entity and not
restrained by JVM semantics), it would be a few steps ahead to where Dart
seems to be heading.

Post by Cristian Garcia
Look at issue #11 <https://github.com/chalin/DEP-non-null/issues/11> I
The proposal states
That is, generally speaking, an unadorned class type T will represent the
non-null type consisting (strictly) of instances of T. When needed, the
meta type annotation ? can be used; ?T denotes the nullable type derived
from T, consisting of values from T or null.
Doesn't the statement
T or null
practically imply/begs for *union types*? Ceylon does this beautifully
where String? is short hand for String | Null. Dart could integrate the
same approach now that its making breaking changes.

['Lasse R.H. Nielsen' via Dart Misc]

Post by Cristian Garcia
Look at issue #11 <https://github.com/chalin/DEP-non-null/issues/11> I
The proposal states
That is, generally speaking, an unadorned class type T will represent the
non-null type consisting (strictly) of instances of T. When needed, the
meta type annotation ? can be used; ?T denotes the nullable type derived
from T, consisting of values from T or null.
Doesn't the statement
T or null
practically imply/begs for *union types*? Ceylon does this beautifully
where String? is short hand for String | Null. Dart could integrate the
same approach now that its making breaking changes.

Pure union types would be nice. If you have them, you might also want
intersection types in some cases, like:
typedef FooFunc(Foo arg);
typedef BarFunc(Bar arg);
foo(FooFunc|BarFunc func, Foo&Bar arg) => func(arg);

Then you have to figure out types like ((Foo & Bar) | (Foo & Baz)), and
whether it's the same as (Foo & (Bar | Baz)). :)

(Never let a good suggestion pass without feature creeping it!)

Dart uses a nominal type system for class types (the declaration is the
type - even if two separate type declarations are identically, they
introduce different types). A union type would probably be a structural
type, like function types. Two different declarations of (Foo|Bar) would
mean the same thing. I don't thing that would be a problem.

Syntax *is* a problem. A pure bar ('|') is already an or operator, so "x as
Foo | bar" already means using the | operator on the Foo value.
Short term it could be done with typedefs:
typedef FooBar = Foo | Bar;
That syntax is unused (and would generalize to aliasing: typedef FooAlias
= Foo; !).
(And could we *please* allow class-scoped and local typedefs! Or just
function type literals :)

Union types is an old request.

/L 'add ALL the features!'
--
Lasse R.H. Nielsen - ***@google.com
'Faith without judgement merely degrades the spirit divine'
Google Denmark ApS - Frederiksborggade 20B, 1 sal - 1360 KÞbenhavn K
- Denmark - CVR nr. 28 86 69 84

[Cristian Garcia]

Might be old, requiere syntax, etc., but it would give NNBD more sense. In
the current proposal "?T" is some hack, it is a union type in a language
that has non. It would be sad that if/when union types are implemented,
"?T" is incompatible with "T | Null" for some reason.

On Wed, Jun 24, 2015, 01:18 'Lasse R.H. Nielsen' via Dart Misc <

Post by 'Lasse R.H. Nielsen' via Dart Misc

Post by Cristian Garcia
Look at issue #11 <https://github.com/chalin/DEP-non-null/issues/11> I
The proposal states
That is, generally speaking, an unadorned class type T will represent the
non-null type consisting (strictly) of instances of T. When needed, the
meta type annotation ? can be used; ?T denotes the nullable type derived
from T, consisting of values from T or null.
Doesn't the statement
T or null
practically imply/begs for *union types*? Ceylon does this beautifully
where String? is short hand for String | Null. Dart could integrate the
same approach now that its making breaking changes.

Pure union types would be nice. If you have them, you might also want
typedef FooFunc(Foo arg);
typedef BarFunc(Bar arg);
foo(FooFunc|BarFunc func, Foo&Bar arg) => func(arg);
Then you have to figure out types like ((Foo & Bar) | (Foo & Baz)), and
whether it's the same as (Foo & (Bar | Baz)). :)
(Never let a good suggestion pass without feature creeping it!)
Dart uses a nominal type system for class types (the declaration is the
type - even if two separate type declarations are identically, they
introduce different types). A union type would probably be a structural
type, like function types. Two different declarations of (Foo|Bar) would
mean the same thing. I don't thing that would be a problem.
Syntax *is* a problem. A pure bar ('|') is already an or operator, so "x
as Foo | bar" already means using the | operator on the Foo value.
typedef FooBar = Foo | Bar;
That syntax is unused (and would generalize to aliasing: typedef FooAlias
= Foo; !).
(And could we *please* allow class-scoped and local typedefs! Or just
function type literals :)
Union types is an old request.
/L 'add ALL the features!'
--
'Faith without judgement merely degrades the spirit divine'
Google Denmark ApS - Frederiksborggade 20B, 1 sal - 1360 KÞbenhavn K
- Denmark - CVR nr. 28 86 69 84
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

['Bob Nystrom' via Dart Misc]

In the current proposal "?T" is some hack, it is a union type in a
language that has non.

Another way to look at it is a syntactic shorthand for the most common
union type. The fact that Dart doesn't currently have a syntax for
*other* union
types might be a missing feature, but that's something we can attend to
later.

It would be sad that if/when union types are implemented, "?T" is

incompatible with "T | Null" for some reason.

I'm pretty certain we wouldn't do that. If we do add union types, I hope
very strongly that we'll be able to retroactively define non-nullability in
terms of them.

Cheers!

- bob

[Cristian Garcia]

Thanks Bob, glad to hear this.

On Wed, Jun 24, 2015 at 11:06 AM 'Bob Nystrom' via Dart Misc <

Post by 'Bob Nystrom' via Dart Misc

In the current proposal "?T" is some hack, it is a union type in a
language that has non.

Another way to look at it is a syntactic shorthand for the most common
union type. The fact that Dart doesn't currently have a syntax for *other* union
types might be a missing feature, but that's something we can attend to
later.
It would be sad that if/when union types are implemented, "?T" is

incompatible with "T | Null" for some reason.

I'm pretty certain we wouldn't do that. If we do add union types, I hope
very strongly that we'll be able to retroactively define non-nullability in
terms of them.
Cheers!
- bob
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

[Sean Eagan]

On Wed, Jun 24, 2015 at 1:18 AM 'Lasse R.H. Nielsen' via Dart Misc <

Post by 'Lasse R.H. Nielsen' via Dart Misc
Pure union types would be nice. If you have them, you might also want

typedef FooFunc(Foo arg);

Post by 'Lasse R.H. Nielsen' via Dart Misc
typedef BarFunc(Bar arg);
foo(FooFunc|BarFunc func, Foo&Bar arg) => func(arg);

You don't want `arg` to be a `Foo` and a `Bar` here, but rather to be a
`Foo` if `func` is a `FooFunc`, or a `Bar` if `func` is a `BarFunc`. So
intersection types wouldn't help... but a combination of union types and
generic methods would:

typedef Func<T>(T)
foo<T extends Foo | Bar>(Func<T> func, T arg) => func(arg);

Personally, I have yet to encounter a use case for intersection types, and
it seems like I could usually just create an interface which implements
both of the types if I did (except for the fact that it's not allowed to
implement some intrinsic types in Dart).

Syntax *is* a problem. A pure bar ('|') is already an or operator, so "x as

Post by 'Lasse R.H. Nielsen' via Dart Misc
Foo | bar" already means using the | operator on the Foo value.

I thought it was a syntax error to include anything other than a type as
argument to `as`, and that seems to check out with a quick analyzer test:

var x = 3;
print(x as int | String);

yields "exptected to find )" on the "|".

['Lasse R.H. Nielsen' via Dart Misc]

Post by Sean Eagan
On Wed, Jun 24, 2015 at 1:18 AM 'Lasse R.H. Nielsen' via Dart Misc <

Post by 'Lasse R.H. Nielsen' via Dart Misc
Syntax *is* a problem. A pure bar ('|') is already an or operator, so "x
as Foo | bar" already means using the | operator on the Foo value.

I thought it was a syntax error to include anything other than a type as
var x = 3;
print(x as int | String);
yields "exptected to find )" on the "|".

Ack, got my precedence wrong, I thought it would be "(x as Foo) | bar", so
that's one bullet dodged.

/L
--
Lasse R.H. Nielsen - ***@google.com
'Faith without judgement merely degrades the spirit divine'
Google Denmark ApS - Frederiksborggade 20B, 1 sal - 1360 KÞbenhavn K
- Denmark - CVR nr. 28 86 69 84