Considering this is a new language, why allow nullable references in the first place? What you call good practice I actually consider a curse.

I agree that it would be better to not compare a null reference at all. A better option would be to return multiple values or have a tuple type and pattern matching.

Like I said, I'm not particularly a fan of Dart.

Don't (typed) Union types work better for errors(with pattern matching) In haskell I think a nullable type or possibly error type frequently returned from functions which can error

ie. data Maybe a = Nothing | Just a data Either a b = Left a | Right b instead of (err,result) like in go

It was hinted in one of the other Dart threads here (or maybe on reddit) that if enough people got on the mailing list and made a good, reasoned case for it that null could still go away.

Tony Hoare's case wasn't good enough?

http://qconlondon.com/london-2009/presentation/Null+Referenc...

> > "String +(Object other) Converts other to a string and creates a new string by concatenating this string with the converted other. " > This is a bad idea, now I have a gripe with dart.

I don't think this is right, and seems to be bad wording on part of the documentation. I don't have any access to an interpreter right now, besides the Google AppSpot in-browser console, but adding a String Object and a Date Object to a new variable does not alter either object or do a forced alter on the existing objects, but rather creates a new string object.

Though, I can't tell if either the date object, or the first string object in this example are altered, it appears that they aren't changed during concatenation: http://try-dart-lang.appspot.com/s/KSAX

That's what the documentation says, imo.

The gripe comes from overloading the + operator, for all I can tell. That's at least the point of the author of the blog post, having + for addition and concatination, with poor type support.

The blog claims that "1" + 1 = "11" (exactly what the docs state here) and claims the same for 1 + "1".