Early draft proposal: Alternative sloppy-mode block-scoped function hoisting semantics

[littledan]

This patch offers an alternative mechanism for sloppy-mode block-scoped
function hoisting, removing the lexical binding for such functions and
making a single, var-scoped binding. Motivation:
https://gist.github.com/littledan/09f08c9bf473a800f5b3
#162

[bterlson]

No consensus for making this change at this time.

[domenic]

In #162 (comment) @bterlson claims "strong reservations about #175 were expressed." That does not match my recollection of the meeting; instead, the reason for rejecting this change was that it was felt that the current spec was still viable. (Not that there was anything wrong with this proposal.)

@bterlson, can you refresh my memory on these strong reservations?

[bterlson]

Unfortunately the notes haven't been published yet (I'll look into it!). That said, I was sitting next to Waldemar when he made numerous arguments against #175 on its own merits (perhaps the term "foot-cannon" will jog your memory?) and he was not alone in expressing these reservations.

I think the takeaway from the conversation was mostly that, as you say, there was vastly insufficient data to suggest the spec needed to change, but assuming it did, #175 was not likely to be accepted based on the negative feedback at the meeting. Of course that could change if #175 were well-motivated and we had to change the spec somehow.

[littledan]

If I remember correctly, the main object had to do with how this violates the new user expectation, established in ES2015, that function bindings are always lexically scoped, and create a difference between sloppy and strict mode. I'd argue the ES2015 semantics are more of a foot cannon (due to the multiple bindings which cause the Inbox issue and I find unintuitive), and sloppy and strict mode already have more probable incompatability risks than this one. But I have to concede that we don't have enough data yet. If it turns out that there are further web incompatibilities once Inbox is fixed, then I think it would still make sense to reconsider this option. We know sloppy mode includes things that we don't like very much but unfortunately can't remove; depending on an empirical evaluation, this "foot-cannon" might be one of them.

[concavelenz]

Generally, "strict" code can run as "sloppy" code, having different
incompatible bindings would make it harder to move from one to the other.
I hope now that the Inbox has been changed to fix its issues, we can see if
there are problems elsewhere.

On Mon, Dec 14, 2015 at 4:43 PM, littledan [email protected] wrote:

If I remember correctly, the main object had to do with how this violates
the new user expectation, established in ES2015, that function bindings are
always lexically scoped, and create a difference between sloppy and strict
mode. I'd argue the ES2015 semantics are more of a foot cannon (due to the
multiple bindings which cause the Inbox issue and I find unintuitive), and
sloppy and strict mode already have more probable incompatability risks
than this one. But I have to concede that we don't have enough data yet. If
it turns out that there are further web incompatibilities once Inbox is
fixed, then I think it would still make sense to reconsider this option. We
know sloppy mode includes things that we don't like very much but
unfortunately can't remove; depending on an empirical evaluation, this
"foot-cannon" might be one of them.

—
Reply to this email directly or view it on GitHub
#175 (comment).