Hacker News Reader

Comment by phpnode | Hacker News Reader

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) { ... }`

View on HN

> 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-vie...

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.

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

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.

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)

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 "The only value that is true is the boolean value true. [...] In a boolean context, everything that is not true is converted to false."

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).

This is true in Go as well 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.

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.

Reply on news.ycombinator.com