Comment by regularfry | Hacker News Reader

Comment by regularfry | Hacker News Reader

Parent Full thread

> This makes as much sense as 'everything' being true. You would write if (true) {...}, but I can't imagine why you would do that.

As I understand it, it's not that you might write if(1){} literally. It's that you might write a method to return <something> on success or null on failure, and ordinarily that would be reusable in a conditional. In Dart, it's not - unless you're careful. This is not the sort of thing we have grown up thinking that we need to be careful about.

Combined with the author's example of a==a potentially evaluating to either false or true depending on the class in a really unexpected way, I'm just seeing potential for confusion and I can't see any immediate reason why they would have thought that this would be a good idea. Yes, the spec mentions JS's problem with an autoboxed false, but they've just moved that problem around, they haven't solved it.

> It's that you might write a method to return <something> on success or null on failure, and ordinarily that would be reusable in a conditional.

Doing this is like writing a pun into your code. Check the type of it, or check if it is equal to null (or if it is not equal to null).

You can even go farther than that -- return true on success, and anything else on failure, and you get the semantics this person wants. If the results should be saved, that should generally be done outside the if condition anyway.

Returning true on success is less useful because in general it's the details of a successful result that you want to operate on. It's less common (but not by any means rare, I admit) for the "happy path" through code to be concerned with details of the error.

> If the results should be saved, that should generally be done outside the if condition anyway.

That's as may be. This is one of those areas where the language is guiding you towards a specific code pattern rather than explicitly preventing something, and I just don't think in this case the guidance is helpful or warranted. I think it's a side-effect of a workaround for a bug in the compilation target, and that's not a good thing to expose at the language spec level.

An example when a==a is when a is NaN

Yeah, but that's literally the only time it makes sense - when you've got a first-class "undefined" or "unknown" type - and if you're going down the path of letting user classes participate in that protocol, I suspect that allowing them to override == in a slightly funky way isn't enough.

Reply on news.ycombinator.com