Not everything. But it's much easier to add than remove a feature, and
here's a couple of the driving issues that make it harder for browsers to
remove these features (browsers remove them before TC39 can):
- `with` is frequently used in templating libraries that use code gen and
allow JS interpol
On Sun, Jul 23, 2017 at 6:49 AM, Jordan Harband wrote:
> There's lots of other threads on why no new modes are likely to ever be
> introduced.
>
And here we see the language evolution committee in its natural habitat
setting itself the impossible goal to support everything every introduced,
stil
On 7/23/17 1:19 AM, Alexander Craggs wrote:
I also feel that it is *impossible* for vendors to add such changes to
make error messages more useful because in the JavaScript syntax
specified ten years ago "await" didn't exist and it would just be an
unexpected string.
Just to be clear, the "unex
On 7/23/17 12:30 AM, Alexander Craggs wrote:
Say we create such versioning, it would allow us to improve the language
so much more than we're currently able to, we'd no longer have to stick
with useless error messages for forgetting `async`:
```js
< function u() { let x = await "hi" }
Uncaught
Sorry, just seen this thread and thought it worth mentioning a similar thread
ongoing here that has derived from wanting to remove less popular features from
the specification:
https://esdiscuss.org/topic/removal-of-language-features
We should definitely continue this conversation in this threa
> > The bottom line here is that browsers aren't a place for a type safe and
> > correct language (well, thy could have been but hey, such is history).
> > They're a medium to consume information over the internet.
due to history, the hard-reality is that its impractical to write
completely correc
For the sake of keeping our discussions clear, could we all please refrain
from flooding the entire mailing list's inbox with these unsubstantial "+1" or
"-1" emails if they contain no meaningful contribution to the conversation?
If you want to make a point, make your point. If not, don't.
Much
> On Jul 23, 2017, at 4:47 PM, Dante Federici
> wrote:
>
> The bottom line here is that browsers aren't a place for a type safe and
> correct language (well, thy could have been but hey, such is history).
> They're a medium to consume information over the internet.
+1
__
A few times now you've proposed a "use _x_" syntax to achieve breaking
changes to the language.
"use strict" is more an attempt to condense the language and take a first
pass best practice. Not a means of "versioning" JS.
The bottom line here is that browsers aren't a place for a type safe and
co
I don't think a new mode is a good idea.
On Sat, Jul 22, 2017 at 10:36 PM, Alexander Craggs <
alexan...@debenclipper.com> wrote:
> Huh, in which case I will!
>
> What are your thoughts on the non-error message part of this proposal?
>
> On 23/07/2017 06:34:48, Jordan Harband wrote:
> Error messa
Huh, in which case I will!
What are your thoughts on the non-error message part of this proposal?
On 23/07/2017 06:34:48, Jordan Harband wrote:
Error messages 1) are unspecified, 2) change all the time, 3) vary by language,
4) vary across browser/engine implementations. There is zero reason that
Error messages 1) are unspecified, 2) change all the time, 3) vary by
language, 4) vary across browser/engine implementations. There is zero
reason that any error message couldn't be changed, and in fact, many
browsers do improve them over time.
I'd say before believing it can't be done, try filin
(Apologies for the double email Jordan, I accidentally replied to just you, not
es-discuss as well. I'm new to this whole mailing list thing.)
Apologies, that was a bad example. I was more considering "use strict" to be
breaking in the sense that some things that worked without it would no lon
Strict mode wasn't a breaking change; browsers that don't understand strict
mode simply ignore the no-op string.
There's lots of other threads on why no new modes are likely to ever be
introduced.
There's also no need to add pragmas or make breaking changes to make error
messages more useful; for
14 matches
Mail list logo