Observing whether a function is strict

Mark S. Miller erights at google.com
Thu May 26 11:34:54 UTC 2016


On Thu, May 26, 2016 at 1:23 PM, Mark S. Miller <erights at google.com> wrote:

>
>
> On Thu, May 26, 2016 at 11:25 AM, Claude Pache <claude.pache at gmail.com>
> wrote:
>
>>
>> > Le 26 mai 2016 à 10:43, G. Kay Lee <
>> balancetraveller+es-discuss at gmail.com> a écrit :
>> >
>> > I was under the impression that strict mode is a (temporary) workaround
>> to get rid of unwanted bad parts of the language without instantly breaking
>> anything. The long term question thus should be: do we have a timeline on
>> the final removal of non-strict behavior from the language, and establish
>> the "strict mode" as the one and only standard behavior. If so, then
>> introducing any additional language feature to help detecting
>> strict/non-strict is certainly not ideal.
>>
>> AFAIK, there is no plan to remove non-strict mode.
>>
>
There are indeed no plans to remove sloppy mode. Fortunately, the desire to
make *new* features available in sloppy mode is waning. Sloppy mode should
be seen only as an ES3 compatibility mode. It is unfortunate that we were
not able to convince the committee not to extend new ES2015 features to
sloppy mode. The result has cost both implementors and users. It cost
implementors a substantial amount of extra work. (In side conversations I
heard shockingly high estimates.) It hurt users by giving extra life to
sloppy mode. None of this was needed for compat. The only compat
requirement at the time was not to break pre-ES2015 sloppy code.
Syntactically, that is essentially identical to ES3.

Hopefully we can avoid repeating this mistake moving forward from here. Let
sloppy mode remain where it is while the rest of the language moves forward.


>> And to be clear about my intentions, what I have in the back of my head
>> was certainly not "introducing any additional language feature to help
>> detecting strict/non-strict" (yuck!), but whether it makes sense to think
>> about a possible way to remove that leak from `Function#arguments` and
>> `Function#caller`. But it would be premature to consider that issue without
>> *at least* an answer to my original question: Are there other ways...?
>>
>
> Hi Claude, what do you mean by "remove that leak"? Hypothetically, let's
> say you had such a test and that it was reliable. How would you use it
> remove the leak? (This is probably also the best way to clarify what
> precisely you mean by removing the leak.)
>
>
>
>>
>> —Claude
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
>
> --
>     Cheers,
>     --MarkM
>



-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160526/34a0e9ea/attachment.html>


More information about the es-discuss mailing list