Conditions in loops processed as AssignmentExpression, should be Expression

@user135362 ,

quite interesting... did not know about this and more so would not even dare to go there... because, when I make compute statements like if (x=a>3) { ...x...; } - and I like to do that a lot - because I'm right away need that x and don't want to spend / waste another few bytes and I'm aware about the resources and the architecture of Espruino - I already get flagged with a warning that an expression is expected and not a assignment.

To be forthcoming for Espruino, it is not Espruino issue but the issue of the IDE - more so its lint - and many other IDEs/lints. I have another attitude borne out of language and compiler building, which is to put the 'continuation-char' on the next line and not at the end... which reduces the error issue greater than 50% and making copying around easy... and makes clear for the reader in the first few chars on the line that things are still going on without having to go read up all to the end of the line - often with scrolling - to figure. (btw, making parens around the assignment hides its very nature and makes lint to see it is a (logical) expression... haha... so much for a machine to control the spirit... of course I could ignore the orange warning triangle.... but I love to also not have to see warnings not to be taken care of. The source is too (2) bytes longer - almost lost what I gained - but to my luck and support: minifier gets rid of it... and if not, let's fix the minifier).

Going on in 'the meta of the metas': the source code has to the way that is is the easiest FOR A HUMAN to read and quickly grok what is going on without having to ingest all things in every detail. The computer - compiler or parser - does not really care anyway and is (most of the time) scalable - I - as a human and individual - I am not scalable.

Returning to the subject at hand: 'getting to know Espruino' taught me and keeps me teaching new things and changes me. Being rooted in general purpose and reuse and (useful) formalism had to give a bit way to what the goal is and is in sync with @Gordon ultimate rational that triggered the birth of Espruino: make it as simple as possible... you could also say: lean as possible. Just because it a thing was done or a spec says you can do it does not mean you should do it... that goes with a teaching I got shoved down the throat very early in my life (cynical): Warum einfach wenn es kompliziert auch geht? - 'translated': why do it simple when it works complicated as well?

Where I see use of this feature of being able to do things in the parens for the condition - may be that's the reason the condition has to be in parens to allow a code block of which the last statement sets the value for the condition - is to not have things stated twice: before the loop's condition is taken into account and the loop starts starts as well as at the end of the loop. That's a typical pattern I never liked and if this will work in Espruino, I will sure take advantage of it; but there is a big BUT: what is the cost in execution and footprint for the interpreter to have to deal with this and make the loop slower than needed.

I can live with many constraints Espruino has, because I could easily declare them as exotic... and exotic coding is against maintenance and against simple growth...

May be not worth 2cts, not even 1, but for sure a 1/2 one... how should I 'feel' about that: :\ ... or :>

So lets fry the bigger fish!