On Thu, Oct 20, 2016, 21:35 Isiah Meadows wrote:
> Please, let's not add a new pragma to the language. `"use strict"` was a
> hack to enable some sanity while still remaining back-compatible, but it's
> not something we should repeat IMHO. (TC39 unanimously
>
...I sent
Please, let's not add a new pragma to the language. `"use strict"` was a
hack to enable some sanity while still remaining back-compatible, but it's
not something we should repeat IMHO. (TC39 unanimously
I would, on the other hand, strongly support dropping most of the
restriction in section 16,
Hi Bergi:
>You're not the only one who is unsatisfied with the current proposal :-) Also
>have a look at
Great! I’m yet to read them but I definitely will soon to discuss more.
>Promises are result values that can be passed to multiple consumers, and not
>every consumer should be allowed to
Ok, what about a "use strict comments"; solution to prevent web breaking?
On Thu, Oct 20, 2016 at 7:33 PM, Rick Waldron wrote:
> Overloading comments is not likely to be accepted as a new feature; doing so
> could be dramatically "web breaking".
>
> You may be interested
Overloading comments is not likely to be accepted as a new feature; doing
so could be dramatically "web breaking".
You may be interested in this:
https://github.com/rwaldron/tc39-notes/blob/master/es6/2014-09/sept-25.md#types
Rick
On Thu, Oct 20, 2016 at 1:14 PM Gert Cuykens
Currently there are two ways to make comments `//` and `/**/` in
Ecma262. I think if Ecma262 has a broader way of implementing comments
it can open up the door for third party type checkers and leave the
burden onto others without the need for transpiling.
I am looking into how close ES20XX
The existence of traps in the language is not an argument for adding other ones.
On the contrary, we must learn from previous problematic design decisions, in
order not to repeat the same errors.
Also, the language feeling more quirky is less a severe issue than the language
inducing to
It's a committee-compromise grammar hack.
On 3:52AM, Thu, Oct 20, 2016 medikoo
wrote:
> ES is already not free from such cases, e.g. `!'property' in object` will
> also not resolve as most will expect.
>
> I understand and agree that case is ambigous and is
ES is already not free from such cases, e.g. `!'property' in object` will
also not resolve as most will expect.
I understand and agree that case is ambigous and is problematic. It just
feels very controversial to me that it was decided that this case will be
handled differently than others that
9 matches
Mail list logo