Compiler assumptions | Hacker News Reader

Compiler assumptions

babel.dev

32 pointsTajnymag8 comments

Sounds like a toolbox full of sharp implements. I guess if you're really performance tuning these would be useful?

The thing is that most of these are severe anti-practices that you probably aren't doing anyway.

Of course, I would still feel pretty nervous turning these on in a large multi-dev codebase unless some corresponding linter rules were also in place.

> The thing is that most of these are severe anti-practices that you probably aren't doing anyway.

Except when you’re doing them by mistake, or because a dependency happened to be clever and you missed it.

See also: UB in every C and C++ code base.

In theory dependencies shouldn't matter, because normally only your own code goes through Babel; library code has typically already been transformed into least-common-denominator JavaScript

Most of these are pretty hard to do by accident... I didn't even know about maybe a third of these things, and I've been writing JavaScript for 10 years

A significant exception to all of the generalizations I've been making is iterableIsArray:

> When using an iterable object (in array destructuring, for-of or spreads), assume that it is an array.

Violating this one is neither an anti-pattern nor hard to do by accident. It would mean a significant shift in practices for a project, and it would have to allow for some really exceptional optimizations if I were going to even consider enabling it

Undefined behavior is overhyped. Most undefined behavior is perfectly defined and supported on the particular platforms being developed for. The official C specification is not a platform.

"Your scientists were so preoccupied with whether or not they could, they didn’t stop to think if they should."

- Jurassic Park. Also, what I think about every time I learn about a "feature" of javascript (like all of the examples in this post) that allows you to do things that would cause any other compiler developer to laugh you out of the room.

My gut reaction was similar, I wish this instead linked to an article explaining some usecases.

I'm assuming if you're writing Babel plugins maybe you want to turn some of these features off so you can make it do alternative behaviour?

Babel usually only processes code you write so, assuming that the developer isn’t relying on document.all being falsy or similar makes sense: !document.all === true is surprising and the sort of thing that should be banned with lint rules.

Also, a lot of compilers have ways to enable normally unsafe transformations: in sbcl, for example, if you (declare (safety 0)), the compiler will just automatically trust your type declarations and generate machine code that is unsafe if this assumption isn’t true: it’s useful because sometimes “correct” behavior has an unacceptable performance cost.

Reply on news.ycombinator.com