> Every use of operators can be considered a syntax trick

That's blatantly false for strict languages, like JavaScript. For a function, all arguments are evaluated before the function is evaluated. For operators this is not true. On the and-case, the second argument is only evaluated if the first one evaluates to something true-ish.

You can only use this supposed and()-function, if you pass closures instead of values and not every language has those.

Then we should consider these reserved keywords and run a transpiler on our code that converts those to the unholy && and || syntax that makes the code really hard to read. You shouldn't expect every junior programmer to invest the necessary time to learn the meaning of all this archaic symbol salad.

While at it we should also remove curly braces and go with Basic's if/end if, function/end function and so on.

`&&` and `||` are very well defined (for the better part, there's languages where `||` does more than just Logical OR.), this double-not hack is just a hack, and can be achieved in many more ways. Stop trying to be obfuscatingly clever, the right time and place for that is outside of professional environments. You don't go around applying tricks from Hacker's Delight without explaining them, do you?

This operator is not currently common for intended audience of my code. And also, it's intended meaning is so much less often useful than meaning of other operators, that I don't think it ever becomes common.

But using the '&&' operator is common enough, while using something like the Javascript void operator would not be, and so would need in a shared codebase a reason for usage other than to try to look smart.

Well, surely that comparison is a bit unfair. :) In my books, using `~~` is closer to shit like abusing `[]+[]` to get an empty string, than using `&&` which is its own separate, widely used operator in the language.

You could maybe compare `~~` to something like `if (!someString)` but, again, that's a widely used and way more easily understood pattern.

Not just widely used in this language but in others, and the meaning of & is clear even in English.

&& is a syntax element whereas ~~ is 2.

Further you're using a side effect of ~ to get rounding. It isn't being used for its intended purpose.

I get your point and to some extent agree with it.

It's more in the class of

While(foo++ = bar++)

You can do it, but you're to some extent abusing constructs.

If it becomes widely used then it's acceptable, but if not it deemed as bad code. Or clever, depending on your world view.

Of course in Perl, a language not exactly immune from "syntax tricks", `and` doesn't always behave the same as `&&` :)

    $ perl -E 'say 1,2,3,4 and 5; say 1,2,3,4 && 5'
    1234
    1235

Not defending it as sensible, but that difference in precedence is deliberate...not an oversight or side effect.

This is not the same at all. What OP does is a *hack* to convert some arbitrary value to a number. This should be very explicit, to avoid having 9999999999999999999999999999999999 and 1 more way to do the same thing.

The issue is that it's a JS only syntax trick. Things like x || y, or even !!x work in most languages, so would be readable to someone who has never used JS before and is trying to read your code base. ~~x would be int32(x) or int(x) in most other languages, so it's not going to be something that's universally learned.

Also, there are multiple ways to convert to int (~~ is equivalent to truncate). Why leave it ambiguous instead of using Math.trunc / Math.floor / Math.ceil?