6 ms·

This seems rather odd from example 14: // Boolean expressions need to resolve to either true or false, as no // implicit conversions are supported. I'

by phpnode 12y ago

This seems rather odd from example 14: // Boolean expressions need to resolve to either true or false, as no // implicit conversions are supported. I'm sure they have good reason for this, does anyone know of the rationale? I think I'd miss patterns like `if (arr.length) { ... }`

sgk284 12y ago
Implicit coercion is often a source of bugs. Some languages simply mandate that you be explicit about your intent. It can be slightly more verbose, but you gain clarity and reduce ambiguity. With implicit coercion, the programmer must mentally keep track of how values get coerced (are negative numbers truthy? are empty strings? empty lists? empty objects?). Different languages have different answers for all of these things. As a result, I prefer to always be explicit. If you've never seen the WAT?[1] talk, I suggest watching it. It has some great examples of type coercion gone wrong in Ruby and JS. [1] https://www.destroyallsoftware.com/talks/wat https://www.destroyallsoftware.com/talks/wat
- spankalee 12y ago
  Being explicit is great, but it doesn't prevent a library from defining it's own boolean coercion rules. The Angular team, for instance, has defined toBool() (which they use in directives like ng-if) like this: bool toBool(x) { if (x is bool) return x; if (x is num) return x != 0; return false; } It treats true and non-zero numbers as true, and everything else (including null) as false.
oblique63 12y ago
> I think I'd miss patterns like `if (arr.length) { ... }` At least for this particular example, dart supports an 'isNotEmpty' property on all iterables[0], so it'd just be this: if (arr.isNotEmpty) { ... } The core libraries support a lot of useful properties like that. [0] https://api.dartlang.org/apidocs/channels/stable/dartdoc-viewer/dart-core.Iterable#id_isNotEmpty https://api.dartlang.org/apidocs/channels/stable/dartdoc-vie...
- munificent 12y ago
  It's actually important to prefer .isNotEmpty over .length here. In some iterables (think generators, or sequences transformed by higher-order functions), calculating the length requires traversing the entire sequence where .isNotEmpty can stop after finding a single item.
berns 12y ago
I think this is wrong or at least misleading. According to the Ecma standard: Boolean conversion maps any object o into a boolean. Boolean conversion is defined by the function application (bool v){ assert(v != null); return identical(v, true); }(o)
- dragonwriter 12y ago
  Reading your quote from the ECMA standard, "no implicit conversions are supported" may be wrong but at the same time not generally misleading. That is, that function errors on null values and returns false for anything that isn't identical to true, so while it does provide a conversion to boolean from any non-null value, anything that isn't exactly a boolean "true" (unless I misunderstand what "identical" does) is going to return false on conversion. This is consistent with other writings on booleans in Dart [1]. So it appears that Dart has implicit boolean conversions, but it converts everything that is not the single "true" value to false, so using an expression that never can evaluate exactly to boolean true in a conditional (unless you mean it to be a wordy way to create unreachable code) is never something you want to do. [1] http://blog.sethladd.com/2012/02/booleans-in-dart.html http://blog.sethladd.com/2012/02/booleans-in-dart.html "The only value that is true is the boolean value true. [...] In a boolean context, everything that is not true is converted to false."
- spankalee 12y ago
  It's subtle. The conversion rule states that only `true` is true, `null` is an error, and everything else is false. However, the type annotation of `bool` means that in checked mode any non-bool value will cause a type error to be thrown. The reason it's defined this way is for efficient compilation to JavaScript. Control-flow constructs don't have to perform a type-check, just a null check (which can be left out in cases due to null propagation).
nickpresta 12y ago
This is true in Go as well http://play.golang.org/p/Mk6i0Ll8uW http://play.golang.org/p/Mk6i0Ll8uW I rather like that you're forced to be explicit. Often, the (hidden) conversion is a source of bugs or confusion.
andreasvc 12y ago
Are you really worried about having to type 2 characters ('>0') more? I think people are too worried about syntax when it comes to programming languages. I guess it makes sense because that is what is most obvious when you look at a language for the first time.

by phpnode 12y ago

sgk284 12y ago

Implicit coercion is often a source of bugs. Some languages simply mandate that you be explicit about your intent. It can be slightly more verbose, but you gain clarity and reduce ambiguity. With implicit coercion, the programmer must mentally keep track of how values get coerced (are negative numbers truthy? are empty strings? empty lists? empty objects?). Different languages have different answers for all of these things. As a result, I prefer to always be explicit. If you've never seen the WAT?[1] talk, I suggest watching it. It has some great examples of type coercion gone wrong in Ruby and JS. [1] https://www.destroyallsoftware.com/talks/wat https://www.destroyallsoftware.com/talks/wat

spankalee 12y ago
Being explicit is great, but it doesn't prevent a library from defining it's own boolean coercion rules. The Angular team, for instance, has defined toBool() (which they use in directives like ng-if) like this: bool toBool(x) { if (x is bool) return x; if (x is num) return x != 0; return false; } It treats true and non-zero numbers as true, and everything else (including null) as false.

oblique63 12y ago

> I think I'd miss patterns like `if (arr.length) { ... }` At least for this particular example, dart supports an 'isNotEmpty' property on all iterables[0], so it'd just be this: if (arr.isNotEmpty) { ... } The core libraries support a lot of useful properties like that. [0] https://api.dartlang.org/apidocs/channels/stable/dartdoc-viewer/dart-core.Iterable#id_isNotEmpty https://api.dartlang.org/apidocs/channels/stable/dartdoc-vie...

munificent 12y ago
It's actually important to prefer .isNotEmpty over .length here. In some iterables (think generators, or sequences transformed by higher-order functions), calculating the length requires traversing the entire sequence where .isNotEmpty can stop after finding a single item.

berns 12y ago

I think this is wrong or at least misleading. According to the Ecma standard: Boolean conversion maps any object o into a boolean. Boolean conversion is defined by the function application (bool v){ assert(v != null); return identical(v, true); }(o)

dragonwriter 12y ago
Reading your quote from the ECMA standard, "no implicit conversions are supported" may be wrong but at the same time not generally misleading. That is, that function errors on null values and returns false for anything that isn't identical to true, so while it does provide a conversion to boolean from any non-null value, anything that isn't exactly a boolean "true" (unless I misunderstand what "identical" does) is going to return false on conversion. This is consistent with other writings on booleans in Dart [1]. So it appears that Dart has implicit boolean conversions, but it converts everything that is not the single "true" value to false, so using an expression that never can evaluate exactly to boolean true in a conditional (unless you mean it to be a wordy way to create unreachable code) is never something you want to do. [1] http://blog.sethladd.com/2012/02/booleans-in-dart.html http://blog.sethladd.com/2012/02/booleans-in-dart.html "The only value that is true is the boolean value true. [...] In a boolean context, everything that is not true is converted to false."
spankalee 12y ago
It's subtle. The conversion rule states that only `true` is true, `null` is an error, and everything else is false. However, the type annotation of `bool` means that in checked mode any non-bool value will cause a type error to be thrown. The reason it's defined this way is for efficient compilation to JavaScript. Control-flow constructs don't have to perform a type-check, just a null check (which can be left out in cases due to null propagation).

nickpresta 12y ago

This is true in Go as well http://play.golang.org/p/Mk6i0Ll8uW http://play.golang.org/p/Mk6i0Ll8uW I rather like that you're forced to be explicit. Often, the (hidden) conversion is a source of bugs or confusion.

andreasvc 12y ago

Are you really worried about having to type 2 characters ('>0') more? I think people are too worried about syntax when it comes to programming languages. I guess it makes sense because that is what is most obvious when you look at a language for the first time.