Strawman union proposal question regarding intersection

[bernaferrari]

75% of my union usage in TS is

void method(data: A | B)

As the proposal says, intersection is hard, so maybe for now Dart could avoid data.something where something exists in both A and B.

But... Just having A | B in the parameter and being able to switch between them would be extremely helpful for me!! I hate using dynamic or object. And I hate using a second variable that's not null when the first one is.

So, this would be extremely helpful to me:

int method(data: A | B) =>
switch(data) {
A: return 1, 
B: return 2,
}

Yet I hear "is" is really really expensive. So maybe this is faster than comparing by "is" twice.

Any thoughts?

I'm not sure opening an issue is the correct path, just wanted to contribute to the discussion.

[ykmnkmi]

Dart way to do this:

// Base class for A & B
abstract class AB {
  int get something;
}

class A implements AB {
  @override
  int get something {
    // ...
  }
}

int method(AB data) {
  return data.something;
}

void main() {
  print(method(A()));
}

[bernaferrari]

Yes, but then you get really limited and you can't do a lot of things. The proposal is a solution for this.

[Wdestroier]

@ykmnkmi the "Java way" works for simple cases, only when these classes are under our control. The same can't be done for void press(String | int key), dynamic process<T>(Stream<T> | Iterable<T> elements) or String hash(String | List<int> input). The latter because String (and possibly more sealed/final classes in Dart 3) can't be implemented. Another huge issue is naming classes. In the A and B example the super class name is AB. In the hash example the type name could be StringOrListInt, HashInput or possibly another bad name that will polute the namespace. The extra boilerplate may decrease the code quality too. Even if interfaces were the solution, I would still need much more creativity and naming things in programming is very hard sometimes.

[ykmnkmi]

@Wdestroier Dart way to do this:

void processStream<T>(Stream<T> stream);
void processIterable<T>(Iterable<T> iterable);

int hash(String input);
int hashBytes(List<int> inputBytes);

For example look at SDK code.

[bernaferrari]

Thanks @ykmnkmi.

I just want to have colors: List<Color | Gradient>. This alone would be extremely helpful for me.

[bernaferrari]

This is 80% of what I want, just add a | and a few other things:

[munificent]

With the upcoming support for pattern matching, you will be able to write:

method1(Object e) {
  switch (e) {
    case num n: // Use n...
    case String s: // Use s...
    case bool b: // Use b...
  }
}

[bernaferrari]

Now if you could just replace Object with num | bool | String.. I would be extreeeeemely happy. Shouldn't be "too much effort" (at least compared to everything else you have planned including most of union features). This alone would help me a lot.

[bernaferrari]

BTW, does the upcoming pattern matching allow for:

method1(Object e) {
  switch (e) {
    case Area n: // Use n...
    case Circle s: // Use s...
  }
}

?

Because on the proposal I need to use Area(var s), but is there a "wildcard" where 'Area' alone would be valid for anything that contains type Area?

[munificent]

They are different patterns. A pattern like Area n matches any value of type Area and binds it to a new variable named n. A pattern like Area(:var n) matches a value of type Area, then calls the n getter on that object and binds the result to a variable n.

[bernaferrari]

What I never understood is where this 'n' came from. Like, if it is var n I'm adding a new variable, right? But what if it is named? Could it be Area(value: var n)? Or is it just syntax sugar to say a new variable is coming as part of the result? lol

BTW, thanks for the explanation, it makes even easier to do what I want. Unionssss, please 😭.

[munificent]

Like, if it is var n I'm adding a new variable, right? But what if it is named?

With an object pattern, it is always named because we need to know what getter to call. It's just that we allow you infer the name from the variable. Area(:var n) means the exact same thing as Area(n: var n).

Could it be Area(value: var n)?

Yes.

[satvikpendem]

It's just that we allow you infer the name from the variable. Area(:var n) means the exact same thing as Area(n: var n).

Is this related to #1123, ie the feature in other languages where you can elide the argument name of named arguments if they're the same? In JS for example in an object { n: n } this becomes { n }. Other languages however don't allow you to fully elide the argument name without some sort of marker like a semicolon, to make it less confusing, such that the above example becomes { :n }, or in the case of functions, foo(:n). Does that mean Dart is also getting this feature?

[bernaferrari]

No, it is just a way of saying "this is the output variable" so you can play with it later. You are kind of declaring something that hasn't appeared yet. It is different, but it is a great idea.