I fail to see how temp is bringing anything useful to ECMAScript that can't already be achieved using let and const declarations. Recall both are block-scoped, which means they should logically be freed from memory after executing exits their scope (assuming there're no lingering pointers). Furthermore, having two keywords that're abbreviations of "temporary" and "variable" would undoubtedly invoke confusion among users.
Finally, the most practical reason to disallow a reserved identifier is the notion of breaking existing code. How many scripts do you envision have used the name temp as an identifier? On 24 March 2016 at 23:00, <[email protected]> wrote: > Send es-discuss mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://mail.mozilla.org/listinfo/es-discuss > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of es-discuss digest..." > > Today's Topics: > > 1. "Temp" as a var type (Brian Barnes) > 2. Strictness of BindingIdentifiers of functions with "use > strict" directives (Kevin Gibbons) > 3. Re: Re: Strictness of BindingIdentifiers of functions with > "use strict" directives (Mike) > 4. Re: "Temp" as a var type (Micha? Wadas) > > > ---------- Forwarded message ---------- > From: Brian Barnes <[email protected]> > To: es-discuss <[email protected]> > Cc: > Date: Wed, 23 Mar 2016 18:13:15 -0400 > Subject: "Temp" as a var type > Another of my "throw ideas at the wall to deal with high performance code > in a GC world.” Thanks for putting up with this! > > A new variable declaration keyword “temp” that declared variables that are: > > 1) Stack based > 2) Locked to their declared type > > I know engines probably do some of this work already, or at least try to > as a optimization. > > Usage would be: > > foo() > { > temp x=0; > temp y=0.1; > var z; > … > } > > z would be on the heap. X is an integer, on the stack, and y is a float, > on the stack. > > Requirements: > > 1) temp variables would always have to be initially declared for typing > (i.e., temp x=0;) It’s also possible you could instead do a pseudo forward > thinking type system, temp x:int32; > 2) changing the type results in an error > 3) returning a temp results in an error > 4) popped off the stack on the function epilogue > 5) always has to be something that can be expressed as a primitive (i.e., > no strings or other objects, they are errors) > 6) Would always be hoisted to help the engine > > An open question would be — what happens if they are passed into a further > function? In my mind, from least to best: > > 1) error > 2) they are passed as if constants, i.e., > > foo() > { > temp x=0; > x++; > foo2(x); // would actually be as if the code was foo2(1); > eventually would be making a new heap object (I assume) > } > > 3) “temp” is carried through to the next function > > Pros: Keeps things out of GC > > Cons: Would probably be difficult to implement and if javascript got > types, this could be done automatically if the type was something that > could be stack based which would make this vestigial and ultimately useless > code, something I wouldn’t want in an engine > > [>] Brian > > > ---------- Forwarded message ---------- > From: Kevin Gibbons <[email protected]> > To: es-discuss <[email protected]> > Cc: > Date: Wed, 23 Mar 2016 15:14:49 -0700 > Subject: Strictness of BindingIdentifiers of functions with "use strict" > directives > Consider the following code: `function static(){'use strict'}`. > > As far as I can tell, this is a legal Script. It would not be if `static` > is considered to be in strict mode code, since it would then be a reserved > word. However, the directive only makes the associated function code strict > (10.2.1), which does not include its BindingIdentifier: > > Function code is defined to be "source text that is parsed to supply the > value of the [[ECMAScriptCode]] and [[FormalParameters]] internal slots of > an ECMAScript function object" (10.2). In particular, this does not appear > to include the name of a function declaration or expression. > > Despite its apparent legality, all of [v8, SpiderMonkey, JavaScriptCore, > ChakraCore, Nashorn] do not allow it, nor does any parser I tried except > Shift. > > Is this intended to be legal? > > > ---------- Forwarded message ---------- > From: Mike <[email protected]> > To: [email protected] > Cc: > Date: Wed, 23 Mar 2016 20:08:24 -0400 > Subject: Re: Re: Strictness of BindingIdentifiers of functions with "use > strict" directives > There was a good discussion about this around this time last year on the > ECMAScript BugZilla tracker: > > https://bugs.ecmascript.org/show_bug.cgi?id=4243 > > Allen showed how this is a little less straightforward than it might first > appear, but he proposed a solution that could work. > > > > ---------- Forwarded message ---------- > From: "Michał Wadas" <[email protected]> > To: Brian Barnes <[email protected]> > Cc: es-discuss <[email protected]> > Date: Thu, 24 Mar 2016 10:03:07 +0100 > Subject: Re: "Temp" as a var type > > It won't help anything. Imagine following example: > > class Foo{ > constructor() { > global.someArray.push(this) > } > } > function baz() { > temp foo = new Foo() > } > > You still have to perform garbage collection to reach global.someArray. So > "stack allocation" that you have proposed won't help engine to optimize > anything except primitives. > And primitives can be optimised anyway by escape analysis without special > syntax. > On 23 Mar 2016 11:13 p.m., "Brian Barnes" <[email protected]> wrote: > >> Another of my "throw ideas at the wall to deal with high performance code >> in a GC world.” Thanks for putting up with this! >> >> A new variable declaration keyword “temp” that declared variables that >> are: >> >> 1) Stack based >> 2) Locked to their declared type >> >> I know engines probably do some of this work already, or at least try to >> as a optimization. >> >> Usage would be: >> >> foo() >> { >> temp x=0; >> temp y=0.1; >> var z; >> … >> } >> >> z would be on the heap. X is an integer, on the stack, and y is a float, >> on the stack. >> >> Requirements: >> >> 1) temp variables would always have to be initially declared for typing >> (i.e., temp x=0;) It’s also possible you could instead do a pseudo forward >> thinking type system, temp x:int32; >> 2) changing the type results in an error >> 3) returning a temp results in an error >> 4) popped off the stack on the function epilogue >> 5) always has to be something that can be expressed as a primitive (i.e., >> no strings or other objects, they are errors) >> 6) Would always be hoisted to help the engine >> >> An open question would be — what happens if they are passed into a >> further function? In my mind, from least to best: >> >> 1) error >> 2) they are passed as if constants, i.e., >> >> foo() >> { >> temp x=0; >> x++; >> foo2(x); // would actually be as if the code was foo2(1); >> eventually would be making a new heap object (I assume) >> } >> >> 3) “temp” is carried through to the next function >> >> Pros: Keeps things out of GC >> >> Cons: Would probably be difficult to implement and if javascript got >> types, this could be done automatically if the type was something that >> could be stack based which would make this vestigial and ultimately useless >> code, something I wouldn’t want in an engine >> >> [>] Brian >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
