When Expression/Statement

[Yissachar Radcliffe]

Kotlin has a nice when expression that can be used for control flow: http://kotlinlang.org/docs/reference/control-flow.html#when-expression

Consider the following if-else:

if (obj is String) {
  print("string");
} else if (obj is List) {
  print("list");
} else {
  print("object");
}

This can be more cleanly expressed as:

when (obj) {
  is String -> print("string");
  is List -> print("list");
  else -> print("object");
}

I find when to be much easier to read then if-else chains, especially for one-liners.

This can be implemented in Dart as either an expression or a statement, though making it an expression would touch on the same issues with making if statements expressions (e.g. implicit returns).

Thoughts on whether this would be a nice addition to Dart?

[Jan Mostert]

What would be the purpose of "when" other than replacing if-else-chains ?

--
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 email to misc+uns...@dartlang.org.

[Günter Zöchbauer]

It would also be a more powerful/less restricted switch. 

[Jan Mostert]

Wouldn't adapting a switch statement be cleaner than introducing a when keyword?

switch(obj, nofallthrough:true){

  case is String => print("string");

  case is List => print("list");

  default => print("object");

}

[Günter Zöchbauer]

It's not only about fallthrough, switch only allows to compare integer, string, or compile-time constants that don't have custom == implementation. 

See also http://japhr.blogspot.co.at/2012/03/dart-switch.html

[Jan Mostert]

Having the ability to set flags on how a switch statement runs would be useful, the nofallthrough:true would probalby the most useful one.

In the cases where you're doing switch(object) or something that's not integer / string / constant, it would be nice if dart can treat it as if it's an if-else statement.

[Joel Trottier-Hébert]

Pattern matching was asked several times in the past in feature requests (I asked it too) and it was just refused.

Hopefully someone asks it again formally and they might consider it.

[Paul Brauner]

I also would like to see pattern matching in dart but not that this request is about something much simpler: this is about bringing something akin to scheme's cond to Dart. This is simpler than pattern matching because clauses don't introduce new bindings, and because you don't have to define what it means to deconstruct an object (which might break encapsulation if done wrong).

That said, if this were added to the language, it would be good to do it in such a way that a possible future addition of pattern matching would be compatible.

Paul

[kc]

On Friday, October 9, 2015 at 9:41:49 AM UTC+1, Günter Zöchbauer wrote:

It's not only about fallthrough, switch only allows to compare integer, string, or compile-time constants that don't have custom == implementation. 

See also http://japhr.blogspot.co.at/2012/03/dart-switch.htm

Developers checking out Dart are probably looking for an alternative to the weirdness/trickiness of JS and restrictiveness of Java.

But a Dart core form - 'switch' - is both weird/tricky and restrictive.

Dart 2.0 - fix or an alternative form.

K. 

[kc]

Right - you could imagine a new cond/match/switch 'form' in Dart 2.0 - which leaves the door open to further enhancements - like patterns - in a backward compatible manner.

K.

[kc]

On Friday, October 9, 2015 at 7:20:53 AM UTC+1, Jan Vladimir Mostert wrote:

What would be the purpose of "when" other than replacing if-else-chains ?

It's expressive. The lack of expressiveness compared to other langs was a core reason for the lack of take up of Dart 1.x imo.

The trick is for Dart 2.x to add new forms/syntax/semantics while maintaining a core simplicity.

The sweet spot for Dart 2.0 is something  both more lighter/expressive then C#/Java and structured/saner than JS/ES.

Dart doesn't have the restriction of a public byte code VM (C#/Java)  or backward compatibility with the bizarre (JS/ES).

K.

[Bob Nystrom]

I'd like to see pattern matching too. I actually wrote up a rough internal proposal for it years ago before we even launched publicly.

In particular, I think it would help our inference story in places where the current type promotion rules currently fall down. Consider code like this:

class Box {

  final num value;

  Box(this.value);

}

main() {

  Box boxed = new Box(12.34);

  if (boxed.value is int) {

    print(boxed.value.isEven);

  }

}

You would hope there is no warning inside the body of the if. But analysis has no way of know the .value getter returns the same value every time you call it, so the previous is check on the result tells it nothing about the later usage of it. You end up having to write redundant code like:

  if (boxed.value is int) {

    print((boxed.value as int).isEven);

  }

If we had pattern matching—a way to do a type test and bind a new scoped variable in one step—you'd have a cleaner way to express this. This is why almost every language that does inference also has some kind of type-test-and-bind syntax or eventually gets one.

– bob

[Yissachar Radcliffe]

Paul is correct that this feature request is not dependent on pattern-matching, though that would be great to add.