Re: ECMA-262: ElementList : ... AssignmentExpression? Wtf?

Expression is .comma expression so can't be used without fatal ambiguity: is [a,,b] [(a,b)] or [(a), (b)]? It's the latter by using AssignmentExpression. If it were PrimaryExpression, ever expression using a binary operator would need to be parenthesized. Is the "Dragon Book" still in print?

Re: Re: FW: Removal of language features

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

Re: FW: Removal of language features

living language. /be On Wed, Jul 26, 2017 at 3:06 PM Florian Bösch <pya...@gmail.com> wrote: > On Wed, Jul 26, 2017 at 11:41 PM, Brendan Eich <brendan.e...@gmail.com> > wrote: >> >> Those languages forked and some modernized (I remember Fortran 77). Thos

Re: FW: Removal of language features

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)

Re: FW: Removal of language features

. It shall continue. /be On Wed, Jul 26, 2017 at 11:37 AM Florian Bösch <pya...@gmail.com> wrote: > On Tue, Jul 25, 2017 at 11:50 PM, Brendan Eich <brendan.e...@gmail.com> > wrote: >> >> Core language changes are different in kind from sync touch events. It's >>

Re: Re: FW: Removal of language features

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

Re: Re: FW: Removal of language features

One thing that may not be obvious: On Wed, Jul 26, 2017 at 8:52 AM Brendan Eich <brendan.e...@gmail.com> 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

Re: Re: FW: Removal of language features

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

Re: Re: FW: Removal of language features

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

Re: FW: Removal of language features

This thread makes me want to unsubscribe from es-discuss. I think I recreated the list. :-( Please read https://esdiscuss.org/topic/no-more-modes and https://esdiscuss.org/topic/use-es6-any-plans-for-such-a-mode#content-2. "Don't break the web" is not some vague high-minded notion of TC39's.

Re: Existential Operator / Null Propagation Operator

You need to be very careful hacking around in an ad-hoc parser. It's easy to diverge from the formal (and verified) grammar by accident. Ambiguous grammars with ad-hoc disambiguation rules codified only by your parser's source code are bad business. Voice of experience here. /be On Sat, May 21,

Re: monadic extension to do-notation

We'll get it on the next TC39 meeting's agenda. /be On Mon, Feb 22, 2016 at 5:28 PM Alan Johnson wrote: > If this is done, please go with `async do { … await … }`. May as well > reuse existing syntax as much as possible. As mentioned, `<-` is > problematic both from the

Re: monadic extension to do-notation

And draft ES6 tried for monadic, but compatibility with Promises libraries (more than "convenience") prevailed. /be On Sun, Feb 7, 2016 at 11:35 AM Raphael Mu wrote: > In theory it's possible, but Promise.resolve automatically joins Promises > for the sake of

Re: monadic extension to do-notation

+1 to experience report from nodent, and +many to futures or eventual values. We've discussed before in terms of value types, value proxies, "become". See, e.g. https://twitter.com/brendaneich/status/585858406742786048 Also: Monadic for sure. Too late for promises. Sometimes you end up taking

Re: Paren-free heads strawman

y 2016 at 18:46, Brendan Eich <brendan.e...@gmail.com> wrote: > >> On Mon, Feb 1, 2016 at 8:02 AM kdex <k...@kdex.de> wrote: >> >>> [Douglas Crockford](https://www.youtube.com/watch?v=Nlqv6NtBXcA) and >>> [Brendan Eich](https://brendaneich.com/2010/11/par

Re: Paren-free heads strawman

t; >> >> >> Since C derived from B, virtually any language that derived from it >> adapted to this redundant syntax; nowadays, the parens exist solely for >> decoration. >> >> >> >> [Douglas Crockford](https://www.youtube.com/watch?v=Nlqv6NtBXcA)

Re: Paren-free heads strawman

On Mon, Feb 1, 2016 at 8:02 AM kdex <k...@kdex.de> wrote: > [Douglas Crockford](https://www.youtube.com/watch?v=Nlqv6NtBXcA) and > [Brendan Eich](https://brendaneich.com/2010/11/paren-free/) seem > > to be in favor of making them optional; that's why the strawman exists. >

Re: Class member encapsulation

C++ has static inheritance and typing. this->A::x is 1 after B's constructor delegates to A's constructor, and this->B::x (a different field) is 2 once that field has been set in B::B. JS has (not yet, anyway) no field declarations, no namespacing akin to A::x and B::x, and so only one this.x to

Re: HTML-like comment behavior inconsistent

Thanks, Claude. It may be tempting to assume the standard specified something dumb, or due to "legacy" mysteries. Not so. HTML5 fully specifies , which I created in 1995 at Netscape. I had no time for the src= attribute, and even if I had (I implemented that in 1996 for Netscape 3), but basis

Re: HTML-like comment behavior inconsistent

Apologies for formatting problems -- I blame the Google Inbox web app. One typo fix, hope it's obvious already: On Sat, Jan 2, 2016 at 2:28 PM Brendan Eich <brendan.e...@gmail.com> wrote: > Thanks, Claude. > > It may be tempting to assume the standard specified somethi

Re: [ small request - Javascript for javaing]

Thanks, Bob. Always good advice. Turns out I'm a list admin still. I will set mod bits if necessary. This has been necessary only a few times over the past ten years. Let's leave this thread to die, please. Happy New Year! /be On Fri, Jan 1, 2016 at 10:06 AM Bob Myers wrote: >

Re: Legitimate uses of IIFEs?

Definitely could have `async` block that's allowed to contain `await`. IIRC we have mooted that at TC39. /be On Mon, Dec 21, 2015 at 9:48 AM wrote: > Ok, I'm convinced :) > > Whether the solution is to invent new syntax or not is moot. It occurred > to me that 'async' could

Re: Propose simpler string constant

Hi Rick, thanks to you and Mike for drafting. I will read and comment more when I have time, but I wanted to channel the Twitter-ghost of Dave Herman: "we should start from pattern matching and work our way from there into the kinds of datatypes we want to match on" I hear wycats and bterlson

Re: Re: Propose simpler string constant

On Wed, Dec 16, 2015 at 9:41 AM Alican Çubukçuoğlu < alicancubukcuo...@gmail.com> wrote: > How are enums declared? > ```javascript > let myVar = 13; > enum myEnum = {Red, Green, Blue}; > No `=` between name and `{`. Enumerator scope is a good question. Clearly we do not want global scope.

Re: es-discuss Digest, Vol 106, Issue 46

t; On Wed, Dec 16, 2015 at 5:44 AM, Brendan Eich <brendan.e...@gmail.com> > wrote: > > `enum` has precedent -- C-like languages indeed use integers by default, > but > > see Rust for a generalized form: > https://doc.rust-lang.org/book/enums.html > > -- for a categor

Re: Propose simpler string constant

What's wanted is `enum { APPLE, ORANGE, GRAPE }` instead. Turns out `enum` was one of four Java-ish future reserved words that IE actually reserved from the ancient days. So we could use it. Some half-formed talk of using it to define categorical sum types, and even value types -- i.e., allowing

Re: Re: Save Object.observe()! (please) + make WeakMap/WeakSet observable.

On Thu, Nov 5, 2015 at 12:30 AM Romuald Quantin wrote: > What is the problem in accessing the keys with any code, which is the same > behaviour for any other object in javascript: String, Array, Object and so > on. The point is being able to do on a weak key so code can be

Re: Save Object.observe()! (please) + make WeakMap/WeakSet observable.

I did watchpoints in SpiderMonkey in 1997 IIRC, implemented as replacement accessors under the hood. ES5 and unfrozen ordinary objects allow self-hosting of watchpoints (ES6 weakmaps and symbols help but are not required). We can't standardize watchpoints for all objects, of course. /be On Thu,

Re: Save Object.observe()! (please) + make WeakMap/WeakSet observable.

You wrote 1. "pretend all object's are really just proxies to whatever their internal backing might be." 2. "without a baked in ability to intercede." 3. "What this does is give you something VERY close to a built in observable Model type on top of plain objects." These are not consistent

Re: Save Object.observe()! (please) + make WeakMap/WeakSet observable.

Ah yes, the Smalltalk "become:" message, something that inspired SpiderMonkey's "Brain Transplants" -- see the [1] footnote at https://brendaneich.com/2010/11/proxy-inception/, and of course the bugzilla link, which leads to this: <https://bugzilla.mozilla.org/user_profil

Re: An update on Object.observe

> a lot of noise on this list Agreed (re: no one in particular). :-( Best to step back and study all of the stuff already in JS, before doubling down on reviving another withdrawn proposal. /be ___ es-discuss mailing list es-discuss@mozilla.org

Re: Exponentiation operator precedence

Because C (B, BCPL, Algol). Too late to change JS where people do tricks such as !-x. No win in risking compat break. /be On Fri, Sep 25, 2015 at 4:18 AM Herby Vojčík wrote: > > > Herby Vojčík wrote: > > > > > > Claude Pache wrote: > >> > >> I just wonder why it is important

Re: Exponentiation operator precedence

Quick update from TC39 yesterday where Rick and I presented the Stage 3 Exponentiation Operator proposal: http://rwaldron.github.io/exponentiation-operator/ The current spec, revised to match precedent from all known programming languages that have exponentiation operators, binds -x^y =

Re: Exponentiation operator precedence

[Apologies for resending, trying to fix formatting of grammar excerpts. /be] Quick update from TC39 yesterday where Rick and I presented the Stage 3 Exponentiation Operator proposal: http://rwaldron.github.io/exponentiation-operator/ The current spec, revised to match precedent from all

Re: Exponentiation operator precedence

Here's a nicely formatted jsbin version of my message: http://jsbin.com/bihilaveda Sorry about the mess, mail user agents (at least Postbox) and archive software do not like explicit indentation. /be ___ es-discuss mailing list

Re: Exponentiation operator precedence

Even nicer: http://jsbin.com/baquqokujo I hate email. /be Brendan Eich wrote: Here's a nicely formatted jsbin version of my message: http://jsbin.com/bihilaveda Sorry about the mess, mail user agents (at least Postbox) and archive software do not like explicit indentation

Re: Exponentiation operator precedence

gmail.com> > wrote: > >> >> Le 24 sept. 2015 à 16:11, Brendan Eich <bren...@mozilla.org> a écrit : >> >> And indeed apart from dot (a special form whose right operand must be a >> lexical identifier-name) and square brackets (which isn't an infix operator >

Re: Exponentiation operator precedence

o include > in the language. > > > > *From:* Brendan Eich <brendan.e...@gmail.com> > *Sent:* Sep 24, 2015 13:18 > *To:* Mark S. Miller; Claude Pache > *Cc:* es-discuss > *Subject:* Re: Exponentiation operator precedence > > Right. It's confusing because (as

Re: Exponentiation operator precedence

it to stage 3 :-P.) /be On Thu, Sep 24, 2015 at 2:05 PM, Claude Pache <claude.pa...@gmail.com> wrote: > > Le 24 sept. 2015 à 22:20, Brendan Eich <brendan.e...@gmail.com> a écrit : > > Sez you! :-P > > Seriously, the problem you are dismissing implicitly (bad form

Re: Object id, hash, etc?

Tab Atkins Jr. wrote: Using a primitive string as a key can inadvertently leak the value for a long time, as the key might be interned and long-lived, far past the point when your code has dropped the intended references to it. Indeed. Strings do not have observable reference semantics at

Re: Object id, hash, etc?

For posterity: http://wiki.ecmascript.org/doku.php?id=proposals:hashcodes http://wiki.ecmascript.org/doku.php?id=discussion:hashcodes (from ES4 daze, a long time ago.) /be Michael McGlothlin wrote: Is there a reason not to provide an object id and hash value as other languages often do? I

Re: Object id, hash, etc?

Michael McGlothlin wrote: I'm only seeing a couple comments there - was that all or am I missing something? Did you read the note about security? I think hashes as an overwritable method that returns a number is pretty standard and let's you combine member hashes with simple Bitwise ops.

Re: Global lexical tier

Andreas Rossberg wrote: On 3 September 2015 at 03:50, Brendan Eich <bren...@mozilla.org <mailto:bren...@mozilla.org>> wrote: I don't remember you overcoming the counterarguments about async scripts and event handlers in async-generated/written markup twisting the n

Re: Global lexical tier

As you probably read (agreed, notes are strung out and not well-indexed), we considered that too. It fell to the objection that users certainly want const and class declarations from one script to be usable in subsequent scripts. For let, we didn't want to break symmetry with const and class

Re: Global lexical tier

saam barati wrote: I think we've also hurt ourselves here with regards to considering alternate implementations by having some form of "const" being visible across multiple JS programs for a while now. This property of top-level const being visible across mutliple programs (script elements)

Re: Global lexical tier

Allen Wirfs-Brock wrote: On Sep 2, 2015, at 4:58 PM, Brendan Eich wrote: > saam barati wrote: >> Thanks. Reading now. >> >> I'm clearly bad at email :/ > > Naw, this stuff is always harder to find than it should be. > > I was there, I just re-read

Re: Global lexical tier

Andreas Rossberg wrote: What I mean is that in a model with mutable scope (or worse, the global object) _declarations_ themselves become global effects. Later conflicts can affect all code that has been loaded _before_, e.g. by smashing over an existing binding. I get it, but this is just

Re: Global lexical tier

saam barati wrote: Thanks. Reading now. I'm clearly bad at email :/ Naw, this stuff is always harder to find than it should be. I was there, I just re-read and re-remembered. I do not agree with Allen that some tiny needle was uniquely threaded. Rather, an aesthetic preference for the new

Re: Global lexical tier

Andreas Rossberg wrote: On 3 September 2015 at 01:58, Brendan Eich <bren...@mozilla.org <mailto:bren...@mozilla.org>> wrote: I was there, I just re-read and re-remembered. I do not agree with Allen that some tiny needle was uniquely threaded. Rather, an aestheti

Re: Global lexical tier

We are in rapid-release hell/heaven. This means errata can be issued, and engines can implement the better resolution for those errata, compared to what the last major-version _de jure_ spec mandated. Why not? /be Adam Klein wrote: Note that this behavior in v8/Chrome is only about sloppy

Re: Exponentiation operator precedence

Not to worry, the significant whitespace prospect was (I trust) a warding-off spell. Good of Waldemar to mention Fortress, too. JS, which as source is and will always be minified, indeed requires full-parsing minifiers, so one might naively still entertain the stated prospect. But it's a bad

Re: Exponentiation operator precedence

Yehuda Katz cited an acronym taught when he was a wee lad learning algebra: PEMDAS (Parentheses, Exponentiation, Multiplication/Dviistion, Addition/Subtraction). Who else learned this? There's nothing sacrosanct about binary precedence being generally lower than unary. Consider the property

Re: `null` and default arguments

See https://esdiscuss.org/topic/default-operator-strawman-rather-than#content-13 and surrounding thread. /be Isiah Meadows wrote: I know it's a little late for this, but what was the rationale of using only `undefined` instead of both that and `null` to denote omitted values for optional

Re: UInt8ClampedArray Bitwise operators?

Daniel Ehrenberg wrote: Uint8ClampedArray is more of a historical artifact than something you should actually aim to use. Uint8Array is probably what you'd want to get at as a basis for a user-level library. Thanks for posting this, Daniel. Just to be super-clear (and I was around when it was

Re: please add x .= f()

Do not send Please add messages with two-line, half-baked sketches of extensions to the language. That's just injecting noise with very little signal. The -1 you received will be the answer if pressed from everyone on TC39, I would bet real money. Syntax is expensive, adding it for little

Re: please add orEqual operator

Please search for older proposals on ecmascript.org. You'd find http://wiki.ecmascript.org/doku.php?id=strawman:default_operator ES6 parameter default values took a look of wind out of this one's sails. /be myemailu...@gmail.com wrote: it could be used like this: if ( a == 1 ||= 2 ||=3

Re: Please help with writing spec for async JSON APIs

Exactly! Incremental and async, i.e., streaming. XML quickly needed such APIs (https://en.wikipedia.org/wiki/Simple_API_for_XML, https://en.wikipedia.org/wiki/StAX). JSON's in the same boat. /be Bruno Jouhier wrote: A common use case is large JSON feeds: header + lots of entries + trailer

Re: Syntax shortcut for accessing properties on the current context (this)

Matthew Robb wrote: does it seem reasonable though that if properties get initializers in the class body that they could be considered in scope to everything else defined in the class body? That's a big if, but with the right *declarative*, binding-like syntax, that's plausibly valid

Re: Syntax shortcut for accessing properties on the current context (this)

Michael McGlothlin wrote: I'd rather that prop just match the object the method is actually attached to, regardless of the context of 'this', before continuing searching the tree. Familiar as its done that way in many languages, You mean static (applied to types, including fields in objects)

Re: Instance bound class methods

You're counting on the property assignment being moved into the constructor, where `this` is bound. In a class body in ES6 (without property assignment extension), especially in the top level where method defintiions go, `this` isn't obviously bound to the newly constructed instance. Ok,

Re: Performance of iterator .next() as specified

Generators (in similar manner and for similar reasons as in PEP-380) can return a value via a `return` statement. This requires a pair {value, done}, you cannot do it with a sentinel such as your item (3). BTW at ECOOP in Prague this past week, I heard from folks (I forget whether it was Till

Re: Cross language discussion

Benjamin Gruenbaum wrote: An annual conference sounds like a great opportunity to discuss design goals of languages and long term goals - I am a much less ambitious man than you. I'm just thinking of small scope examples, to name 3 on top of my head: - The iteration protocol (PHP had a

Re: May 2015 Meeting Notes

Andreas Rossberg wrote: A seemingly predictable name is a rather bad idea, because it would be very brittle, e.g., depend on other libraries loaded, or even loading order. It's better to have clearly non-deterministic (e.g. gensym) than something that pretends to be deterministic but isn't in

Re: function.sent beta equivalence?

Andreas Rossberg wrote: But it's a good question. Maybe it's an indication that we should not add function.sent? We talked about this at the last meeting, though maybe you weren't there (meeting notes header with people present and their 2 or 3LAs gets copied forward a lot!). It doesn't seem

Re: function.sent beta equivalence?

Jason Orendorff wrote: My sense is that function.next s/.next/.sent/ is outside this relationship, and it shows as a bit of a wart every time you write abstract code about generators. Yes, agree there's a smell. We did not automate delegating function.sent for good reason, though. Is

Re: revive let blocks

Matthew Robb wrote: I feel like this would just get confused with object destructuring. Not just confused -- it is fatally ambiguous. I think do expressions are go for ES7 but they need re-championing, and implementation. I'll stir the pot. /be

Re: function.sent beta equivalence?

Hrm, the meeting notes don't quite capture it (https://github.com/tc39/tc39-notes/blob/bf5190257d22d1c700e203b28edc8d85ee3aadcc/es6/2015-05/may-27.md is one view; my fault for not editing after), but we have discussed passing function.sent into the sub-generator in the past. Ben Newman first

Re: function.sent beta equivalence?

Jason Orendorff wrote: What does wrap look like? It seems like it would be pretty involved. It might be the full, hideous, but write-once complexity of the desugaring of yield*, but now I'm seeing fragments and missing-uncited-text messages from Mark, and wondering whether I'm missing a

Re: Move es-discuss to discuss.webplatform.org?

Jonathan Kingston wrote: (I don't think any such es-discuss replacement should be on webplatform.org http://webplatform.org/, FWIW -- that crosses the W3C and Ecma streams.) Is that such an issue? I was thinking the larger exposure and closer working would be a bigger benefit than the mail

Re: Move es-discuss to discuss.webplatform.org?

Let's talk about this at July's TC39 meeting. Maybe we can have best of both worlds, thanks to Discourse. (I don't think any such es-discuss replacement should be on webplatform.org, FWIW -- that crosses the W3C and Ecma streams.) Having two es-dis{cuss,course} list-like things is not great.

Re: Move es-discuss to discuss.webplatform.org?

Axel Rauschmayer wrote: My biggest concern is that you can’t be selective in your consumption of es-discuss: It’s all or nothing (even if you only want to participate occasionally). The volume is daunting, esp. with a mobile device. Long ago we had USENET and NNTP to help avoid having to

Re: Move es-discuss to discuss.webplatform.org?

Allen Wirfs-Brock wrote: Or perhaps ecaa could host. Ecma? HAHAHAHA! Ahem. Sorry. Judging from the IT outsourcing our people in Geneva do, I can only say: nope! Am I being unfair? Their Francs are as gold/green/orange/etc. (https://en.wikipedia.org/wiki/Banknotes_of_the_Swiss_franc) as

Re: Move es-discuss to discuss.webplatform.org?

Allen Wirfs-Brock wrote: On Jun 22, 2015, at 12:51 PM, C. Scott Ananian ecmascr...@cscott.net mailto:ecmascr...@cscott.net wrote: It's not too surprising: it's the same reason why the ES6 spec was just published *on paper*, with the html version being explicitly flagged as non-normative.

Re: When macros will get in, will the core get slimmed in favour of macro-definitions?

Sure, we'd want that. And sweet.js can handle a lot (it handled classes, destructuring, and other ES6 features before they were implemented in popular engines). This may take a while. Best way to ensure this outcome: more people learning, using, and helping improve sweet.js. /be

Re: The Tragedy of the Common Lisp, or, Why Large Languages Explode (was: revive let blocks)

Good points, Mark. There are two better ways forward that I see: 1. Separate forms and make them compose well. Instead of let (x=y){z} and the grammatically unsound let (x=y)x*x from ES4, given let in ES6, and do expressions in ES7, declare victory and use `do { let x = y; z }`. 2. Sweet.js

Re: {Spam?} Re: Language design

I think we can stick a fork in this thread, it's done. Let it memorialize some knowledge that seems in danger of being lost over time. Thanks, /be Wes Garland wrote: That root post ignored compatibility constraints that have been discussed to death over the years, and just glibly asserted

Re: @@isConcatSpreadable

Herby Vojčík wrote: So when one actually _wants_ to concat (as, add elements of the iterable), it should stop using concat for that and must do something like var concatenated = first.slice(); concatenated.push(...second, ...third, ...fourth); Or use concat but wrap the parameter with [].

Re: Language design

Edwin Reynoso wrote: Yes please edit it, you don't have to repost. BTW the only thing I can agree with is the `Object.is()` which to me seems like the only problem it solves is `Object.is(NaN, NaN)` now returns true You didn't agree with the root post (whose sender has had the mod flag set

Re: Look-behind proposal

I will do it if no one else steps up by 10pm tonight PDT. Thank you to Nozomu Katō for writing it up! /be Sebastian Zartner wrote: So the question is, how to recruit a TC39 member? Through this list? Is it possible to become a member as a private person?

Re: Existential Operator / Null Propagation Operator

Sam Ruby wrote: I think that the problem here isn't that it is ambiguous, it is that it isn't obvious. Fair point! Something that might be more obvious but requires an additional character: `orders.?[client.key].price`. That's not bad. The whole proposal may founder, though, on grawlix

Re: Promise sub-class: super((resolve, reject) = this) ?

With best intentions I must say that you are overreacting. The subject-line code (h/t Mark Miller for pointing me at it!) in context of the superclass constructor uses `this` before `super` has returned. That's a no-no for pretty-good reason. If you have a better alternative design, we needed

Re: Existential Operator / Null Propagation Operator

Sander Deryckere wrote: For the prefix operator, it's unclear to me how you would do the following: Say you know `obj` is non-null, you want to test if it has a key `k1`, but if `k1` exists, you know it will also have a key `k2` a level deeper. With the suffix operator, this would be

Re: Existential Operator / Null Propagation Operator

Sander Deryckere wrote: 2015-06-02 17:49 GMT+02:00 Brendan Eich bren...@mozilla.org mailto:bren...@mozilla.org: Sander Deryckere wrote: For the prefix operator, it's unclear to me how you would do the following: Say you know `obj` is non-null, you want to test

Re: import ModuleSpecifier

to specify this aspect of the language makes no sense to this developer at least. On Sun, May 31, 2015 at 7:30 PM, Brendan Eich bren...@mozilla.org mailto:bren...@mozilla.org wrote: Browsers in any semi-competitive market will agree on a standard. I don't see why that needs to be called

Re: Maybe we need a reflect API to iterate over instance members

Domenic Denicola wrote: However, in the end, what you need to do to get something into the language is to prove that it's a common enough need that it's worth adding complexity to the spec and implementations. This thread is very far from doing that. A better start would be surveying

Re: Maybe we need a reflect API to iterate over instance members

Alexander Jones wrote: Or since Proxy traps correspond 1-to-1 to the internal methods in the spec, the primary goal of the Reflect API was to expose the essential methods that make up Javascript's object model as defined by the spec. I like this definition. Is it written

Re: 2 questions about ES6 module loaders

Glen wrote: PS. from X import Y syntax would have been useful in cases where IDEs provide auto-completion. I know it's too late for changes now. It has other advantages: Python-like for those who care; Y can be a long braced list or pattern, which goes better at the end. But too late, and

Re: import ModuleSpecifier

Browsers in any semi-competitive market will agree on a standard. I don't see why that needs to be called into doubt, even as part of a hypothetical future :-|. (Is there another kind? :-P) /be Domenic Denicola wrote: Yes, in theory. However, browsers are more likely to wait until there’s a

Re: Class decorators and async process

Alexandre Louis Marc Morgaut wrote: Sync is out of bounds in browsers, and for Node.js apart from require -- a rift indeed between the two embeddings. Just to be fair, Sync is still appreciated in some situations in JS like - in Dedicated Workers, Good point. Still not in specs but proposed

Re: why not just import new language into browser?

I would like to suggest that everyone let this thread die. It's way out of scope for es-discuss, and three kinds of bogus just considering the Subject: line. If anyone wants to chat about it, HN has regular recurring why not blub? and why not bytecode threads. /be (co-moderator with @awbjs)

Re: Label statement moveable

I'm not sure what you mean by limited goto, but your example works since ES3 in JS. Underused part of the design: break from labeled block or if, no need for do-while(0) nonsense. /be Michał Wadas wrote: I'm not sure if limited goto should be really considered harmful. Dijkstra has written

Re: Label statement moveable

Claude Pache wrote: Anyway, for rare cases not covered by `break label`, as you noted, proper tail call is a satisfactory way to spell `goto`: ``` ;(function foo() { // ... if (bar) return foo() // ... })() ``` +∞ /be ___

Re: Class decorators and async process

Gray Zhang wrote: It’s OK, I just wait for |this.weapon| to resolve, but then my |hit| method becomes async, and everything based on |@inject| property should be async, which is not actually what I want. Async can be contaminating, yes. Sync is out of bounds in browsers, and for Node.js

Re: let function

; then why not for the block-bodied case too, so readers are better reminded that `this` is from the outer scope, ditto `arguments`? Decisions, decisions! /be Brendan Eich wrote: Your point about decorators vs. hoisting is good, everyone should keep it in mind. Still doesn't mean we can't add

Re: Label statement moveable

Bob Myers wrote: Can we also get goto statements? No, although an out-of-shipping-date Opera engine supported them. Also, if we going to do gotos, then please implement computed GOTO. FORTRAN has had that already for like 50 years. Sorry, JS is not Fortran. Goto considered harmful,

Re: let function

Your point about decorators vs. hoisting is good, everyone should keep it in mind. Still doesn't mean we can't add a special form for const function, as followups aver. /be Alexander Jones wrote: On 19 May 2015 at 02:02, Brendan Eich bren...@mozilla.org mailto:bren...@mozilla.org wrote

Re: let function

C. Scott Ananian wrote: On Tue, May 19, 2015 at 12:24 PM, Steve Fink sph...@gmail.com mailto:sph...@gmail.com wrote: That visually collides with destructuring for me. let [a, b] = foo(); let {a, b} = foo(); let f(a, b) = foo(); # Very different I almost expect that last

Re: let function

I post this followup with some trepidation, as the es-discuss S/N ratio has dropped badly in recent weeks. Perhaps esdiscourse is doing better? Anyway, discussion fodder: @rauchg messaged me recently wondering why let f = (x) = y; could not be shortened to let f(x) y; This seems like a

Re: Not forcing super in derived class's constructor?

Glen Huang wrote: maybe subclassing that particular class is not the correct abstraction here; I think the need for inheriting methods and the need for a totally different way of preparing the object are orthogonal. There's a saying taught (I'm told) in law school: hard cases make bad law.

Re: 'stream' values

I've been working to put the JavaScript in Java since 1995 :-D. /be Tab Atkins Jr. wrote: On Thu, May 7, 2015 at 12:36 AM,mohan.radhakrish...@cognizant.com wrote: That was helpful. I find it interesting that ES6 code is very similar to Java 8 lambdas. The relationship is closer to the

  1   2   3   4   5   6   7   8   9   10   >