f() = x de facto standard
To be honest, I was championing that parser writers should write flexible and supportive parsers and put strict ocd parsing under a flag/option. Especially in this case, where you need a parser that should be able to parse content parsable by a number of other parsers (-> browsers), you want your parser to be as accepting as possible or it's useless in those contexts.
I'm not saying "bring back f()=x" :) I don't see any point in that
myself. Thanks though, David.
Aligning with reality is the point. A web standard is pointless if it doesn't describe reality. That's one of the reason the WHATWG was founded and one of the reason versioning is an anti-pattern on the web.
Standards follow reality, not the other way around the vast majority of the time (unlike the common belief). Standards not following reality make themselves de facto obselete. That's why W3C HTML snapshots are a cute but useless idea (bugs in spec snapshot versions never get fixed by definition of a snapshot). Among other things, that's also the reason why getting implementation of native promises right the first time is important. If implementations diverge, the spec will have to be fixed and likely to something that isn't satisfactory.
Anyway, if you're not saying "bring back f()=x" and if it is confirmed
to be a de facto standard, then I am saying it :-) (and will add it to
ECMAScript Regrets, because it's doesn't seem like something people
should write)
Perhaps we could ban it in strict code specifically? This would also include module and class bodies, allowing us to shed it over time without breaking compat.
On Aug 7, 2013, at 4:08 AM, David Bruant wrote:
Hi,
From qfox.nl/weblog/291 Apparently, "f() = x" was forbidden as of ES5.1 (was still available in ES5 apparently), but a jQuery plugin is using it [1] (path not triggered in non-IE browsers). Not breaking the web, all that. It should probably be brought back.
I'm not sure where that analysis came from? As far as I know there were no such changes in ES5.1 and the ES5.1 grammar clearly allows a function call to appear on the LHS of an assignment.
That said, this is something we did discuss for ES6 and the current ES6 draft has a static semantic restriction that disallows assignment to the result of the function call. In addition, functions are no longer allowed to return Reference values. I don't see us changing the latter, so it comes down whether the error is reported as an early syntax error or a runtime TypeError.
On Wed, Aug 7, 2013 at 7:08 AM, David Bruant <bruant.d at gmail.com> wrote:
Hi,
From qfox.nl/weblog/291 Apparently, "f() = x" was forbidden as of ES5.1 (was still available in ES5 apparently), but a jQuery plugin is using it [1] (path not triggered in non-IE browsers). Not breaking the web, all that. It should probably be brought back.
In [1] below, that doesn't do anything and never did. In jsfiddle.net/rwaldron/XPCMm/show/light nothing will ever get logged. When run in IE6, 7, 8 there will be an error on the page.
On Wed, Aug 7, 2013 at 6:21 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>wrote:
I'm not sure where that analysis came from? As far as I know there were no such changes in ES5.1 and the ES5.1 grammar clearly allows a function call to appear on the LHS of an assignment.
I got it from code.google.com/p/esprima/issues/detail?id=81#c19, maybe I should have dug deeper to confirm it...
In addition, functions are no longer allowed to return Reference values. I don't see us changing the latter, so it comes down whether the error is reported as an early syntax error or a runtime TypeError.
Probably what the bug is about.
From qfox.nl/weblog/291 Apparently,
f() = xwas forbidden as of ES5.1 (was still available in ES5 apparently), but a jQuery plugin is using it 1 (path not triggered in non-IE browsers). Not breaking the web, all that. It should probably be brought back.Syntax isn't my cup of tea, so I'll let others judge if a detail was overlooked somewhere.
Kudos to @kuvos on this one!