Maybe TC39 should think about a deprecation plan, which includes rules
for fairness between browser vendors. For example, if the feature
`RegExp.$1` shall be removed. Then:
1. At date X, the feature gets marked as deprecated.
2. Within 6 Months from X, all browser vendors must have taken this
I agree. The only people who really have a stake in this discussion apart
from committee members are implementors, and trust me: they really don't
like having to support features deprecated for over a decade.
My only question at this point is: would it be possible to emit deprecation
warnings for
I read this discussion for a long time and I do not see anything which
helps anyone...
I see TC39 members/supporters who say, there is no issue for them still
having the old features in place:
Brendan Eich (TC39): "There's no evidence (I'm sitting in a TC39
meeting) other than grumping from
To clarify, I'm just a normal, non-committee person. So that's a "I like
the idea and it looks workable", but not "I'll champion this for you" (when
I can't).
On Wed, Jul 26, 2017, 21:41 Isiah Meadows wrote:
> That, I could support.
>
> On Wed, Jul 26, 2017, 16:38 Alexander Craggs
> wrote:
>
>>
That, I could support.
On Wed, Jul 26, 2017, 16:38 Alexander Craggs
wrote:
> In which case, perhaps change this proposal to .slice(start, end, step)
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discus
On Wed, Jul 26, 2017 at 3:37 PM, Florian Bösch wrote:
> On Thu, Jul 27, 2017 at 12:18 AM, Brendan Eich
> wrote:
>>
>> The solution is not to hate JS. It's not going to change incompatibly.
>> Rather, you can use linters, "transpilers", compilers, voluntary unchecked
>> subsets -- all possible tod
I feel like a reticence on starting a new version of JS. After all, JS is only
at version 1 and has survived at least 20 years. Every software, including
languages, are having major versions with breaking changes. And I don’t see why
JS should be an exception. That just would be great to make a
On Thu, Jul 27, 2017 at 12:18 AM, Brendan Eich
wrote:
> The solution is not to hate JS. It's not going to change incompatibly.
> Rather, you can use linters, "transpilers", compilers, voluntary unchecked
> subsets -- all possible today.
>
So basically "the best way to use JS is to not use JS". A
On Wed, Jul 26, 2017 at 11:59 AM Michał Wadas wrote:
> I know that's hard to remove features from the web. That's why I propose
> *clear
> and well defined *route to clean up language.
>
Instead of asserting in bold, why not answer the questions I posed in reply
to your clear but incomplete pro
Languages have warts, not just JS. No cleanup is perfect, and more warts
come over time. If your point is merely about a "language you hate" but
must perforce use on the Web, I think you should be happy right now. The
solution is not to hate JS. It's not going to change incompatibly. Rather,
you c
On Wed, Jul 26, 2017 at 11:41 PM, Brendan Eich
wrote:
>
> Those languages forked and some modernized (I remember Fortran 77). Those
> are all quite a bit older than JS. I would also suggest they are for the
> most part stunning successes. We've learned a lot from them.
>
Yes, but we'll also want
On Wed, Jul 26, 2017 at 12:14 PM Florian Bösch wrote:
> On Wed, Jul 26, 2017 at 9:00 PM, T.J. Crowder <
> tj.crow...@farsightsoftware.com> wrote:
>>
>> keeping it alive and healthy beyond its browser-limited existence.
>>
>
> Many languages (including Python and Perl) concluded that at some poin
> There are some features of x86 which where ditched. The more well known
example would be MMX (though the idea lives on in SSE/SIMD). But then
there's also ARM and its slow crawl to replace x86 ...
MMX was not in the original set and looks more like an abandoned experiment
(a bit like ES-4). But
On Wed, Jul 26, 2017 at 9:50 PM, Alexander Craggs <
alexan...@debenclipper.com> wrote:
> Oops, I'm an idiot and didn't see this.
:-) Just FWIW for future (and lurkers), proposals are listed in the
[proposals repo](https://github.com/tc39/proposals) (that links to active;
also check "inactive" and
Oops, I'm an idiot and didn't see this.
On 26/07/2017 21:49:11, Logan Smyth wrote:
There is currently an active proposal for this:
https://github.com/tc39/proposal-numeric-separator
[https://github.com/tc39/proposal-numeric-separator]
On Wed, Jul 26, 2017 at 1:47 PM, Alexander Craggs mailto:ale
See [1].
[1] https://github.com/tc39/proposal-numeric-separator
On Wednesday, July 26, 2017 10:47:27 PM CEST Alexander Craggs wrote:
> Large number are hard to read in JavaScript, is 2384923842 over a billion?
> Or just several hundred million. One solution to this some languages have
> used is
There is currently an active proposal for this:
https://github.com/tc39/proposal-numeric-separator
On Wed, Jul 26, 2017 at 1:47 PM, Alexander Craggs <
alexan...@debenclipper.com> wrote:
> Large number are hard to read in JavaScript, is 2384923842 over a
> billion? Or just several hundred million
Large number are hard to read in JavaScript, is 2384923842 over a billion? Or
just several hundred million. One solution to this some languages have used is
to allow underscores within numbers. You can immediately recognise
2_384_923_842 is a number in the billions, rather than millions.
It w
In which case, perhaps change this proposal to .slice(start, end, step)___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Wed, Jul 26, 2017 at 9:47 PM, Bruno Jouhier wrote:
> JavaScript is often referred to as the "assembly language of the web". Did
> any instruction ever get removed from the x86 instruction set? Will this
> ever happen?
>
There are some features of x86 which where ditched. The more well known
e
> requires browser use
Nope. Both Discourse + NodeBB allow the ability to use them as a mailing list.
Thus, they require nothing more to use than the current system. (You require
a browser to sign up, but mailing lists here require the same thing as well).
> long term archival
I would argue
> But no other environment have a goal to be backward compatible *forever*
JavaScript is often referred to as the "assembly language of the web". Did
any instruction ever get removed from the x86 instruction set? Will this
ever happen?
Also, modern C compilers still compile C code written in the
On Wed, Jul 26, 2017 at 9:00 PM, T.J. Crowder <
tj.crow...@farsightsoftware.com> wrote:
>
> keeping it alive and healthy beyond its browser-limited existence.
>
Many languages (including Python and Perl) concluded that at some point
things have to be "cleaned up". The track record of languages th
1. There's no evidence (I'm sitting in a TC39 meeting) other than grumping
from a few that we are near the point of JS painted into a corner by
backward compatibility.
2. WebAssembly is happening. Dynamic language support will take a while.
Together these suggest JS evolution will continue. It s
On Wed, Jul 26, 2017 at 7:37 PM, Florian Bösch wrote:
> This means JS is not a living language, or won't be much longer in any
case.
"Much longer" is of course entirely subjective, but let's not be too
dramatic; I think we can count on JavaScript being a living language for
*at least* another 10
I know that's hard to remove features from the web. That's why I propose *clear
and well defined *route to clean up language.
Browsers already "broke" the web many times. Java Applets are dead. ActiveX
is dead (though some government websites still require it). Flash will be
dead in few years. And
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 Tue, Jul 25, 2017 at 11:50 PM, Brendan Eich
wrote:
>
> Core language changes are different in kind from sync touch events. It's
> very hard to plan to remove anything on a practical schedule or
> order-of-work basis. Engine maintainers likely still hate more modes, and
> users should too. New s
On Wed, Jul 26, 2017 at 1:56 PM, Brendan Eich wrote:
> Strict mode also made runtime-incompatible changes, e.g. arguments[i] not
> aliasing i'th formal parameter, which required two-way testing while strict
> mode adoption was nascent or partial (which of course many devs skipped).
>
> On Wed, Jul
> On Jul 26, 2017, at 10:56 AM, Brendan Eich wrote:
>
> From my memory of the meetings and online discussions, strict mode was not
> meant to make static analysis significantly easier. More important was
> enabling Caja (now SES) to "use strict" and do less work, static and at
> runtime. Impl
Strict mode also made runtime-incompatible changes, e.g. arguments[i] not
aliasing i'th formal parameter, which required two-way testing while strict
mode adoption was nascent or partial (which of course many devs skipped).
On Wed, Jul 26, 2017 at 9:53 AM Andreas Rossberg
wrote:
> The "ability t
On 26 July 2017 at 18:10, Mike Samuel wrote:
> On Wed, Jul 26, 2017 at 5:55 AM, Andreas Rossberg
> wrote:
> > And clearly, modes or versions only make things worse in that regard.
> Strict
> > mode already is a pig when it comes to implementation complexity (in
> > retrospect, it does not carry
One thing that may not be obvious:
On Wed, Jul 26, 2017 at 8:52 AM Brendan Eich wrote:
> I created JS in 1995. In 1996 I made a few incompatible changes to JS and
> got away with it, but not in 1997. ES3 was done in 1999 based on de-facto
> work in Netscape and IE that converged (mostly; a few e
On Wed, Jul 26, 2017 at 5:55 AM, Andreas Rossberg wrote:
> And clearly, modes or versions only make things worse in that regard. Strict
> mode already is a pig when it comes to implementation complexity (in
> retrospect, it does not carry its weight IMHO). ES6 made it worse. Our
IIRC, the primary
On Wed, Jul 26, 2017 at 4:44 AM Michał Wadas wrote:
> Simple idea:
>
>- Add new Annex to language.
>- Define operation EmitDeprecationWarning(code) - implementations MAY
>show deprecation warning in implementation dependent way (it can depend on
>runtime flag, dev tools, not minif
i had seen some people transform{ doSth(); return;}toreturn
void doSth();for saving the `{}` and line breaks.
So maybereturn arr.forEach(...)is just been written due to same reason.
___
On 26 July 2017 at 17:38, Brendan Eich wrote:
> Hi Andreas, is this the best link to the Strong Mode post-mortem?
>
> https://groups.google.com/d/msg/strengthen-js/ojj3TDxbHpQ/5ENNAiUzEgAJ
>
Yup.
On Wed, Jul 26, 2017 at 2:56 AM Andreas Rossberg
> wrote:
>
>> As for the reoccurring assumption
On Wed, Jul 26, 2017 at 4:31 PM, Allen Wirfs-Brock
wrote:
> Note that the irregular indentation does not occur in the ES2015
> PDF which is a direct rendering of the MS Word source document
> that was in use at that time. The irregular indentation (at
> least then) as an artifact of the HTML rende
Hi Andreas, is this the best link to the Strong Mode post-mortem?
https://groups.google.com/d/msg/strengthen-js/ojj3TDxbHpQ/5ENNAiUzEgAJ
/be
On Wed, Jul 26, 2017 at 2:56 AM Andreas Rossberg
wrote:
> As for the reoccurring assumption that deprecation would help simplifying
> JavaScript implemen
> On Jul 26, 2017, at 6:01 AM, T.J. Crowder
> wrote:
>
>
> **Ouch**, that's time I'd really like back. The problem is in the ES2015 and
> ES2016 specs too, I assumed it had to mean something.
Note that the irregular indentation does not occur in the ES2015 PDF which is a
direct rendering of
On Wed, Jul 26, 2017 at 9:01 AM, T.J. Crowder
wrote:
> On Wed, Jul 26, 2017 at 1:52 PM, Michael Dyck
> wrote:
>> On 17-07-26 07:32 AM, T.J. Crowder wrote:
>>>
>>> Second, the general: What's the significance of the indentation? Some
>>> productions are indented more than others, and I can't see m
On Wed, Jul 26, 2017 at 1:31 AM, Claude Pache wrote:
> Previous discussion:
>
> https://esdiscuss.org/topic/move-es-discuss-to-discuss-webplatform-org
TLDR, that thread raises several issues
* email requires browser use. This was later acknowledged as ironic,
but there was pushback
on account
Ah yeah true there is some overlap there thanks.
On 26 July 2017 at 14:19, T.J. Crowder
wrote:
> I think you're talking about named parameters, or close enough anyway.
> Most recent discussion of named parameters (originally just "is there
> discussion of them?" but it went from there):
> https:
I think you're talking about named parameters, or close enough anyway. Most
recent discussion of named parameters (originally just "is there discussion
of them?" but it went from there):
https://esdiscuss.org/topic/named-paramters
Others probably as well if you search back further in the archives
Hi all
I propose a new syntax for defining function argument hints. If you have a
lot of arguments in a function it can be difficult to remember which
argument is which. Using a hint allows you to easily see the argument
required and can prevent you from passing an incorrect argument.
It would wo
On Mon, Jul 17, 2017 at 12:21 PM, Isiah Meadows
wrote:
> I'd probably raise it there just in case. Worst case scenario, it just
> gets closed.
Done, thanks: https://github.com/tc39/ecma262/issues/959
-- T.J. Crowder
___
es-discuss mailing list
es-discu
On Wed, Jul 26, 2017 at 1:52 PM, Michael Dyck
wrote:
> On 17-07-26 07:32 AM, T.J. Crowder wrote:
>>
>> Second, the general: What's the significance of the indentation? Some
>> productions are indented more than others, and I can't see meaning in it.
>
> No significance, just a styling thing.
> See
On 17-07-26 07:32 AM, T.J. Crowder wrote:
Second, the general: What's the significance of the indentation? Some
productions are indented more than others, and I can't see meaning in it.
No significance, just a styling thing.
See https://github.com/tc39/ecma262/issues/956
-Michael
On Wed, Jul 26, 2017 at 1:38 PM, Sebastian Malton
wrote:
> I propose something list how rust does it. They have a git repo for
> RFCs and that allows people to to star it or just follow the ones
> that they want to follow.
You can do that with the github repos used by TC39 proposals.
This threa
I propose something list how rust does it. They have a git repo for RFCs and that allows people to to star it or just follow the ones that they want to follow.Sebastian
Sorry, I meant to mention that I checked my understanding of that specific
case against the current in-progress TCO implementation in V8 v5.8.283.41
(in Node 8.2.1 behind a flag), and it did indeed happily optimize the first
and not the second:
```js
"use strict";
// Optimized:
function a(val, co
Simple idea:
- Add new Annex to language.
- Define operation EmitDeprecationWarning(code) - implementations MAY
show deprecation warning in implementation dependent way (it can depend on
runtime flag, dev tools, not minified code, etc.); otherwise operation
EmitDeprecationWarning is
I'm wrapping my head around the details of TCO in the spec. Two parts to
this: 1. Could I ask someone to double-check me on a particular
understanding, and 2. What's the significance of some productions in the
various statement and expression rules being indented and set apart from
others? (A probl
As for the reoccurring assumption that deprecation would help simplifying
JavaScript implementations: no, not to a relevant degree. 80+% of the
complexity in a JS VM comes from the plethora of (sometimes ridiculous)
edge cases in the core semantics of JavaScript, its object model, implicit
conversi
54 matches
Mail list logo
