The very low precedence of & is the source of an unbelievable number of bugs, especially in embedded programming. For example:

if(PORTA & 3 != 0)

looks like it should be true if either of the low two bits is set. But actually, it only fires if the low bit is set because this resolves to PORTA & (3 != 0), which is PORTA & 1.

Some C compilers will warn you about this. Embedded C compilers are not usually the sort of compilers that are nice enough to have these warnings.

As a bonus, different languages handle precedence of &,|,^ differently: Python, for instance, binds & more tightly than ==.

It's a shame. C made the precedence blatantly wrong so a few thousand lines of legacy code wouldn't have to be updated.

And then everyone decides their own languages will copy it forever.

That should give a warning at least because it (and this is probably a C thing) treats or implicitly casts a boolean true / false to a 0/1. You shouldn't be able to do PORTA & true.

One more for my list of "why I don't like C".

Depending on what version of C you are using, there are no "boolean" values.

X != Y returns an integer value, no "implicit cast" required for &.

Implicit casts are both convenient and evil. JavaScript deserves its own place for it.

I've never understood why any language does this. To save a few keystrokes? Code is much more read than written.

Javascript and PHP deal with HTML, where input forms can only request text* but are often used for numbers, so the conversion rules are an attempt to automatically treat numbers as numbers instead of forcing programmers to always do the conversion themselves (as other frameworks rely on instead).

With this kept in mind, I've personally found almost all the implicit conversions in both languages to be intuitive.

* You can limit the values to numerics, and nowadays use attributes to handle javascript, but that wouldn't help PHP where it gets encoded to querystring anyway.

In most cases, up or down casting 32 and 64 bit integers would be a shitton of work that barely adds anything. A similar case could be made for casting ints to floats (i.e. 2 + 3.1 should just work).

Beyond that though, most implicit casts are just bad.

> Especially if you think yourself to be clever (narrator: he did).

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."

        — Brian W. Kernighan and P. J. Plauger in The Elements of Programming Style.

I don't contribute much to open source, mostly due to employment agreements, but a couple I was able to make: 1. Bulk copying null values with Python Sybase module (initialized variable used) 2. ACE high res timer bug under x64. Inline ASM was using the wrong registers in x64 mode (reading garbage upper 32 bits of 64 bit value).

Both of these were bizarre bugs, and neither was immediately evident.

#1 was presented by an error saying something to the effect of "received xXxX bytes, expecting yyyy".

#2 was harder. It became evident because of logging. The high res timer was used gor logging amd intermittently, I was seeing +200 years supposedly elapsed during a db operation. Obviously wrong. It was a bug due to how registers are handled between x86 and x64 code.