Re: Power operator, why does -2**3 throws?

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 problematic. It just > feels very cont

Re: Support () => {}() syntax?

Ideally there will be an `async` version of do expressions, which evaluate to a promise: ``` let promise = async do { await something(); }; ``` (BTW, if we get such a thing, we might not really need top-level-module-await...) On Fri, Sep 30, 2016 at 2:39 AM Olivier Lalonde wrote: > Do "do ex

Re: Endorse an unambiguous syntax for ES2015 modules

I suggest re-reading Domenic's two replies; they quite exhaust the topic, I think. On 12:31AM, Wed, Sep 7, 2016 martin heidegger wrote: > > This is not correct. There is nothing backward-incompatible about > adding a new top-level grammar goal. And the new grammar goal has even less > impact on

Re: Reason for strange ExponentiationExpression & UpdateExpression productions?

It's pretty weird. On Wed, Jul 20, 2016 at 3:55 PM Jordan Harband wrote: > `-x ** y` is absolutely a SyntaxError because of the disagreement between > many programming languages which treat that as `(-x) ** y` and math itself > which treats it as `-(x ** y)`. > > To resolve the debate about "wha

Re: A plan to help TC39 become more open up to community contributions and participations

Thanks for pointing out some issues with the current state of things. While, in general, having more people directly participate in the committee is probably a good thing, I don't think that will fix the problem. I think you'll find yourself running into the same troubles that the current members

Re: Import wildcards

With this syntax, you would not be able to statically tell whether a particular variable name (e.g. API_FOO) is bound to a module import, without also analyzing the dependencies (and perhaps their dependencies). These considerations killed the original "import all" syntax. (`import * from 'foobar'

Re: Existential Operator / Null Propagation Operator

> > I will note that JavaScript does already require n-token lookahead worst > case to disambiguate arrow functions from sequence expressions. > The syntax is actually specified in terms of cover grammars, not arbitrary lookahead. ___ es-discuss mailing l

Re: Class and Property Initialization

> > That said, it has one problem -- base classes. You can't seal them > because the constructor in the extended class would fail (I tried it) > and so the base classes would always have to remain unsealed which > means you either (1) understand that or (2) always use an extended class > if you c

Re: Async iteration

> > Is there a summary of the motivation for "for-await" and "async iteration" > in general? > There's a short section at: https://github.com/tc39/proposal-async-iteration#overview-and-motivation > Has there any discussion in not supporting "var" in "for-await" > initializers? > Symmetry with f

Re: Object.prototype.forIn

1. How is a user supposed to intuit the difference between Object.keys and Object.keysIn? For a non-expert, it sounds like the same thing. 2. With "keys", "entries", etc., we lead the user down the "safe" object-as-dict path. Does adding these methods undo some of that leading? What are the compe

Re: Why Proxy "apply" trap limited to function only?

> I thought `typeof (class {}) === "function"` as well. And classes, to my > knowledge aren't callable. > Oh they are, they just throw when you call them : ) https://tc39.github.io/ecma262/#sec-ecmascript-function-objects-call-thisargument-argumentslist Step 2 _

Re: Destructuring an object into a new object (like Underscore pick but ESier)

> > I can create a new object with ALL of these properties using a spread > operator: > let newObj = {...obj, quux: 4} > Let's not do this. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Weak Reference proposal

> > I have no problem with that, but do wonder, why? What is the downside of >> proposals being on the tc39 hub starting at an earlier stage, if the >> authors are so inclined? The upside is fewer broken links. >> > Because having the tc39 "brand" on things sends a signal to the broader community a

Re: Weak Reference proposal

I suggest that this one be left on tc39 since it's already there and there is a history of weakref proposals anyway. But in general we should only move proposals to tc39 at stage . On 6:32PM, Tue, Feb 16, 2016 Mark S. Miller wrote: > On Tue, Feb 16, 2016 at 2:02 PM, Daniel Ehrenberg > wrote: >

Re: Any reason why __proto__ is not a well known symbol?

> > Is there a migration to make it a Symbol in ES7? (ignorant question?) > Object.getPrototypeOf and Object.setPrototypeOf are the "no-dunder" ways to do it. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discus

Re: Are the default Symbol.species accessors intended to be configurable?

> > Is this a correct reading of the spec? Is this a bug in the spec? > https://github.com/tc39/test262/blob/master/test/built-ins/RegExp/Symbol.species/symbol-species.js > tests > that the RegExp[Symbol.species] property is configurable. Additionally, it > appears to break at least one major webp

Re: Why are ES6 class methods not automatically bound to the instance?

> > One of the wonderful features of many prototype methods is that they can > be borrowed and .call-ed on other objects (imagine if you couldn't > `Array.prototype.slice.call(arguments)`!). Auto binding would cripple this > feature, and it seems like opting out would be harder than opting in. In

Re: Try/catch conditional exceptions in light of generators

> > It appears that there are no proposals on the way to deal with it and it > is a very real problem. What would be the correct process to bring more > attention to it? > A proposal posted here : ) A few things to address (off the top of my head): - There was an old proposal for catch guards

Re: monadic extension to do-notation

Why not just use await within `async do`? On 12:19PM, Sun, Feb 7, 2016 Rick Waldron wrote: > What does this do? > > > let finalPromise = do { > let a; > a <- b; > } > > > Currently, that's an expression that means "a less than negated b" > > Rick > > On Sun, Feb 7, 2016 at 12:07 PM Raphael Mu >

Re: Optional Chaining (aka Existential Operator, Null Propagation)

> > In case `myForm.querySelector('select[name=foo]')` is not null, then > `myForm.querySelector('select[name=foo]').selectedOptions` is always an > HTMLCollection and has always a `length` property. If it is not the case, > then either I made a typo, or I am testing some ancient browser that > doe

Re: Optional Chaining (aka Existential Operator, Null Propagation)

> > Yes: the `?.` operator does not change the meaning of the subsequent `.` > operator. I like to think of it as: the effect is local (short-circuiting > aside), you are not switching between "modes". It’s a feature. > Just curious: what's the rationale for that behavior, as opposed to "deep" sh

Re: Optional Chaining (aka Existential Operator, Null Propagation)

Thanks for putting this together. At first glance, I think the semantics look pretty good. The syntax still seems problematic, though, from an aesthetic point of view. The `obj ?. prop` form looks natural and aligns well with how this feature appears in other languages. The other forms are less

Re: Specifying the Existential Operator using Abrupt Completion

> > Since nobody seems to have taken this, I will submit a formal proposal for > stage 0 very soon (before two weeks). > Thanks Claude - looking forward to it! ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discus

Re: Promises as Cancelation Tokens

> > I think F#'s cancellation approach is also worth mentioning in the > discussion of alternatives as it has implicit but token-based automatically > propagating cancellation. > If you have any good links to reference materials on F#'s cancellation architecture, feel free to include them for futu

Re: Promises as Cancelation Tokens

Thanks for posting this. Great stuff! > On a page that loads 100 images four at a time, you would want 4 cleanup > actions registered, not 100. > And in order to keep it to 4 you need a way to unregister the action when you complete the operation, which the promise API doesn't give you. I see.

Re: Promises as Cancelation Tokens

Thanks Ron! Comments inline... > · Once a callback has been registered for asynchronous notification > of a cancellation signal, it can later be unregistered. > Yes, I see how this could be helpful. > · Asynchronous notifications are queued and handled at a higher > priority than Pro

Re: Promises as Cancelation Tokens

> > I think using promises as tokens would be problematic. It would have > several issues: > Agreed with all of those. It's also important to keep in mind that promises can be subclassed so it's > fine to add properties to them if used for a specific purpose like > cancellation. > We could use a

Re: Promises as Cancelation Tokens

> throw() { throw new CancelError() } > This should be `throwIfRequested` I think, e.g. throwIfRequested() { if (this._requested) throw new CancelError(); } } > What would be the recommended way of keeping the internal state > private? With a WeakMap? > Spec-def

Re: Promises as Cancelation Tokens

> > Since checking `promise.state` is synchronous, we may as well just > write a synchronous Cancel class instead: > Right - see upthread. You do need some kind of callback method, though, like `whenCancelled(callback)`. > class Cancel { > constructor() { this.requested = false } > requ

Re: Promises as Cancelation Tokens

> > We have pretty sound cancellation semantics in bluebird 3. > Cool, I'm aware that cancellable promises have been explored in depth. I'd prefer to keep this thread focused on cancellation tokens though, and avoid comparisons. ___ es-discuss mailing l

Re: Promises as Cancelation Tokens

> > The best approach in cases like this is to avoid the word altogether. > The fact that there's confusion at all means people will mess it up > and get annoyed, even if there's a "winner" in overall usage. > Hmmm... Maybe class CancelToken { constructor(init); get cancelRequest

Re: Promises as Cancelation Tokens

> > I am also unsure when .whenCanceled is necessary > Maybe in the case where you have a promise-returning function and you want to reject the returned promise upon cancellation. function delayWithCancel(ms, cancelToken) { return new Promise((resolve, reject) => { setTimeout(re

Re: Promises as Cancelation Tokens

And what's the deal, is it canceled or cancelled? : ) On Mon, Jan 4, 2016 at 11:30 AM Kevin Smith wrote: > Is there a reason to use a Promise as the cancellation token, rather than >> have something that is synchronously inspectable? >> > > The only real downsi

Re: Promises as Cancelation Tokens

> > Is there a reason to use a Promise as the cancellation token, rather than > have something that is synchronously inspectable? > The only real downside of coming up with a new interface is that we have to standardize it. : ) It's a core protocol. I agree that using a promise directly would f

Promises as Cancelation Tokens

I'm interested in exploring the idea of using an approach similar to .NET's cancelation tokens in JS for async task cancelation. Since the cancelation "flag" is effectively an eventual value, it seems like promises are well-suited to modeling the token. Using a promise for a cancelation token wou

Re: Re: The "Pipeline" Operator - Making multiple function calls look great

Sidebar: thanks to Isiah Meadows, the FBS proposal now also supports constructor wrapping via the `::new` syntax: let factory = SomeClass::new; On Mon, Dec 14, 2015 at 9:00 AM Marius Gundersen wrote: > Do we really need to add support for await in a pipeline syntax sugar when > there already

Re: Re: The "Pipeline" Operator - Making multiple function calls look great

It also seems like the current proposal for PO makes it awkward when mixing methods and piped calls in a chain. (someArray .filter(...) .map(...) |> someOtherArrayOp ).forEach(...) Note the extra parens before the "forEach" invocation. Kevin __

Re: Re: The "Pipeline" Operator - Making multiple function calls look great

I can confirm that function bind syntax is all rainbows and unicorns. : p On 9:49PM, Sat, Dec 12, 2015 Alican Çubukçuoğlu wrote: > This is a terrible example. It looks a lot better with what's already > available: > ```javascript > async function runTask () { > const file = await fs.readFile(

Re: The "Pipeline" Operator - Making multiple function calls look great

> > ```js > // Assume fs.readFile is an `async` function > async function runTask () { > './index.txt' > |> await fs.readFile > |> file => file >.split('\n') >.map(fs.readFile) > |> await Promise.all > |> all => all.join("\n") > |> console.log > } > ``` > This

Re: Generator getter method

The existing option is: let rect = { get corners() { return this._corners(); }, *_corners() { .. }, }; which doesn't seem so bad. Also, a generator getter would introduce a bit of divergence between getter and setter syntax. On Tue, Nov 10, 2015 at 2:28 PM Mohsen Azimi wrote: > Can we all

Re: The "Pipeline" Operator - Making multiple function calls look great

> > - I don't like the requirement to use the keyword `this` to compose > functions. JS already has many features to support the keyword `this`: > prototypes, method invocations, function binding, arrow functions, and > probably others. I prefer a feature that assists the other side of the > spectr

Re: The "Pipeline" Operator - Making multiple function calls look great

Hi Gilbert, Have you seen https://github.com/zenparsing/es-function-bind/ ? It's a function bind-syntax proposal which covers some of the same use cases (although by binding the `this` parameter instead of passing the first arg). We've also explored some alternatives more closely aligned with yo

Re: resolve()/reject() on Promise subclasses and @@species

> > Should it be corrected before @@species is widely implemented? I think so. > I agree, if feasible. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Default call constructor behavior

A downside of specifying a default like this is that adding a "call constructor" (can we think of a better name for this?) to an existing class would become a breaking change for users of that class. On Mon, Oct 26, 2015 at 8:49 AM Isiah Meadows wrote: > I was using F.p.partial as merely an ex

Re: Decorators for functions

> > I would just say that it is odd in the extreme that a group of > world-leading language designers would just throw in the towel when > confronted with a pretty small roadbump, instead of figuring out ways to > solve it. > Another drive-by... The trick is introducing new features without explo

Re: Fix Left-Associative Compound Conditional Statements!!

> > Actually, scratch that, its not even JUST a matter of convenience. A > simple evaluation in your developer console will tell you that this > currently evaluates inconveniently (I am avoiding the term "incorrectly" > here because it is not theoretically incorrect if we consider these > evaluatio

Re: Global lexical tier

> > I don't see how strict/sloppy mode effects the behavior of top-level > lexical declarations. Does the behavior depend on strict mode? > No, V8 just currently disallows the use of let/const/class outside of strict mode. ___ es-discuss mailing list es-

Re: Global lexical tier

> > We should have just made toplevel let/const/class create global > properties, like var. This is how it was proposed originally Can you provide (or link to) a more specific proposal? Kevin ___ es-discuss mailing list es-discuss@mozilla.org https://m

Re: JSDoc3-style operator to access property of prototype(s)

> > class Child extends Parent { > method () { > // TODO: do something more than Parent would > return Parent#method.call(this); > This would be written "return super.method();" > var args = Array#slice.call(arguments, 0); > var args = Array.from(arguments); (or rest params) Have al

Re: Computed Property Name Shorthand Proposal

> > I'd expect the following to work, given that the prop expression evaluates > to 'bar', and bar is in context. > > var foo = 'bar' > var bar = 'ponyfoo' > var baz = { [foo] } > console.log(baz) > // <- { bar: 'ponyfoo' } > Hmmm... I'm not sure I would expect any such thing. It seems like you'

Re: Exponentiation operator precedence

> > because the right-side-up way to say that is: > > e - a * c > Yeah, I was waiting for someone to point that out, after I hit send. : ) I should spend more time setting up a better examples... ___ es-discuss mailing list es-discuss@mozilla.org h

Re: Exponentiation operator precedence

> > x ** y ** z is easier to read/write than x.pow(y.pow(z)) > That might be cherry picking. Trying to make up something a little more complex: a**b * -c**d + e Math.pow(a, b) * -Math.pow(c, d) + e a.pow(b) * -c.pow(d) + e I don't have strong feelings on this issue, but the third o

Re: Better place for discussion?

> > Is there a better place than this list to ask design questions that cover > current best practice, upcoming features, and possible improvements to the > language? > We don't generally cover best-practice or programming advice here, but obviously anything to do with extending the language or fi

Re: Re: Existential Operator / Null Propagation Operator

> In TypeScript `?` means optional. But throw if the value is nil is the > same same as non-nullable? > In Swift, the postfix "!" operator unwraps an optional value, throwing if nil. See https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/OptionalChai

Re: Re: Existential Operator / Null Propagation Operator

> > What about `a!?.b` since semantically the symbol `!` has a meaning of > non-nullable in JSDoc[1]. > "!" in this context typically means non-optional, or "throw if the value is nill". See Swift for example. Or just `a!.b`? > Same thing. Kevin ___

Re: Proposal for a null coalescing operator

I just noticed that null/undefined was addressed in the OP, my apologies. Kevin ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal for a null coalescing operator

A link to a wikipedia article is not *actually* a proposal : ) As Michael points out, you need to at least provide some consideration for null vs. undefined. I would also like to see some thought given to how such an operator might interact with a null propagation operator, discussed here: https

Re: String.substitute

> > let yearSentence = ({year:2015}=>`This year is ${year}`)(); > Enclosing the template string inside of a function is the way to go. Let's call this one done. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-disc

Re: Named Arrow Functions

> > My proposal is not a keyword, but an hidden variable included at functions > (e.g. arguments). > Does arrow functions have any limitations about that? > Yes. There are no special contextual keywords reserved within arrow functions. We've discussed the possibility of a "meta property" for thi

Re: Named Arrow Functions

> > x.map(factorial(x) => do { > if (x <= 1) { > 1; > } else { > x * factorial(x - 1) > } > }); > This has been discussed over the years but there has been very little interest in making the grammar more complicated. After all, you can alway

Re: Please help with writing spec for async JSON APIs

Hi Moshen, The semantics of your proposal are straightforward, so I don't think you need to provide spec text at this point. Instead, what would be helpful is a quantitative analysis showing why these additional methods are needed. Is there any way you can demonstrate the benefit with numbers?

Re: await on synchronous functions

> > I know the spec for this isn't finalized, but what is the current > direction for the behaviour when await is used on a function that is not > marked async and doesn't return a Promise? Should it run immediately or > wait for the next turn of the event loop? > More generally, the question is:

Re: for statement with index and value

Destructuring is here to help: for (let [index, value] of [1, 2, 3].entries()) console.log(index + ": " + value) The "entries" method returns an iterator of [index, value] pairs. On Mon, Jul 13, 2015 at 10:13 PM Tingan Ho wrote: > Just following a discussion we had on TypeScript >

Re: Instance bound class methods

> I am curious if https://github.com/zenparsing/es-function-bind would be > related, since it would allow bound function calls to be made by using > `obj::fn` while `obj.fn` would result in the unbound first class function. > Well, for that syntax proposal, it would be `::obj.fn`. But see https:/

Re: Will any new features be tied to constructors?

> > Ah, I see. So what's observable is not whether things are a contiguous > chunk of memory or whatnot but rather whether the slots exist. And a > proposed invariant is that the slots, once observed to exist or not > cannot change that state. Is my understanding correct now? > Yes. ___

Re: Will any new features be tied to constructors?

> > I actually do have a related question, though. In the private state > proposals we're talking about, how would it be observable whether the > private slots the class defines are in fact allocated as part of the > object's allocation or separately? > Not sure I understand the question. If the

Re: Will any new features be tied to constructors?

> > ```js > class Derived extends Base { > constructor(...args) { > super(a, b, c); > doInitCode(this, ...args); > } > } > ``` > > via a function > > ```js > function makeDerived(...args) { > const o = Reflect.construct(Base, [a, b, c], Derived); > doInitCode(o, ...args); > return

Re: Will any new features be tied to constructors?

The fact that you're dynamically changing the prototype as a part of this solution is a strong indicator that this usage of subclassing is somewhat questionable. I suspect that you'll find other gotachas with this approach. I understand that the DOM is dealing with some design constraints that ar

Re: Will any new features be tied to constructors?

> > The essence of Dmitry's design is to disallow custom allocation, while > allowing custom initialization. This allows you to optionally decouple the > two stages when necessary (upgrades, cloning, etc.) while also getting the > goodness where author code doing `new MyElement(...)` calls both bui

Re: Incompatibility between generators and arrays in the Iterator protocol

If you use yield instead of return in your generator function you'll get the desired results. When using a generator function to implement iteration, you'll generally want to avoid returning a final value, since for-of ignores the return value. The return value does have an important role to play

Re: revive let blocks

> > Yes, I'm planning to prepare a proper spec for the September meeting. I'm > also hoping we get a prototype impl in V8 some time later this year, > although I'd rather not promise anything. > Cool - looking forward to it! ___ es-discuss mailing list e

Re: Will any new features be tied to constructors?

> > The design is basically that the browser first creates a "normal" > element, and at a later point changes the prototype and invokes the > callback. Changes the prototype dynamically? We're generally moving away from such shenanigans. That would indeed interact poorly with some of the design

Re: revive let blocks

> > I think do expressions are "go" for ES7 but they need re-championing, > and implementation. I'll stir the pot. > I think Andreas was interested at some point? I've long been interested in the possibility of a "do async" as well. : ) ___ es-discuss m

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

> > ES needs to evolve more rapidly than once every 5-15 years. The yearly > update plan is good, but that doesn't mean we should be rushing proposals > (particularly complex ones) through the process in order to catch the next > yearly release. Bake time is good. There are numerous ES6 features

Re: primitive boxing in instanceof due to Symbol.hasInstance

> > > https://people.mozilla.org/~jorendorff/es6-draft.html#sec-instanceofoperator > calls GetMethod on C without checking if it is an Object, this means `1 > instanceof Foo` could be affected by mutating > `Number.prototype[Symbol.hasInstance]`. > I assume you mean "without checking if O is an ob

Re: Language design

https://i.imgflip.com/mtot6.jpg On Fri, Jun 12, 2015 at 6:55 PM KOLANICH wrote: > Hello all. I have opened the page > https://developer.mozilla.org/en-US/docs/Web/JavaScript/New_in_JavaScript/ECMAScript_6_support_in_Mozilla > and was horrified. What happened with JS? Why do we need all this meth

Re: Example of real world usage of function bind syntax

Derp - email fail! : ) You could always use parenthesis: > ::(whatever).foo But in any case: > Right - I think there are going to be two points of contention regarding > the prefix form: > > 1. Is a unary prefix operator appropriate, given the somewhat "magic" > dereference+bind behavior?

Re: Example of real world usage of function bind syntax

> > A more interesting issue in my view is whether a prefix (`::obj.meth`) is > the best syntax. An infix alternative like `obj->meth` might be interesting > if the left term is itself a complex expression. > You could always use parenthesis: Right - I think there are going to be two points of c

Re: Example of real world usage of function bind syntax

> > I'm not entirely sure if it's appropriate, but I just published a library > called Trine[1] that takes advantage and displays the power of the proposed > function bind syntax. Consider this my upvote for the proposal. :) > It's definitely appropriate, as long as it's clear to users that the `:

Re: ES6 Proxy Function Call Trap

> > So why not do that for ES6 proxies as well by adding an `invoke` trap. > Tom's response a couple of messages back summed it up fairly well. To paraphrase, introducing "invoke" is a reasonable thing to propose (evidenced by the fact that it was part of the spec draft at one point). However, "i

Re: Ideas on type hinting and named parameters

> > how about introducing a well known concept in JS as `own` ? > > ```js > class Person { > static name String: "A person name" > own name String: "anonymous" > own items Array: [] > Let's take a step back and ask: what's the motivation for having these property declarations and initialize

Re: Ideas on type hinting and named parameters

> > Also static properties are on __proto__, so it seems a bit strange that > instance properties would not also be on .prototype. Somewhat of a > consistency issue I suppose. > Methods declared as "static" in ES6 are defined on the constructor itself. Apparently, "static" data properties in TS ar

Re: Ideas on type hinting and named parameters

> > Syntax for putting properties on the prototype was long-ago rejected > because of footgun potential. > Correction: *data* properties. : ) ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Ideas on type hinting and named parameters

> > Anyway, I'm curious to know why do you think getters and setters are OK > and properties are not. I don't see any technical difference, specially > considering get/set for lazy property computation/assignment through the > prototype getter anyway. > Syntax for putting properties on the prototy

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

Hi Logan - that's correct. On Tue, Jun 2, 2015 at 11:08 PM Logan Smyth wrote: > To clarify things, since I don't think it's been made abundantly clear, > the example that Sebastian gave would work in a standard ES6 environment, > correct? It is only if the callback were executed synchronously th

Re: let function

> > function-in-block does not have the same semantics as the proposed "let > function". It hoists, thus has no TDZ, and appears to preclude a reasonable > decorator syntax behaviour, > But that would not fix the decorator/function problem. Specifically, we would not want to have a situation wher

Re: let function

> Good points. All the more reason to throw out declarations as statements > in favour of let/const/var, which we all have to understand well > anyway, for other types of variable. Declarations aren't going anywhere, and there is zero interest in "deprecating" them. You might want to spend a bit

Re: function.next meta-property proposal

Alexander, ES6 generators accept any arbitrary values for the first invocation of "next". That's not going to change. On Thu, May 14, 2015 at 3:49 PM Alexander Jones wrote: > In Python, sending a value other than `None` into the first invocation of > `send` raises an error. That seems like a re

Re: let function

Why not use a function declaration instead? On Thu, May 14, 2015 at 2:37 PM Alexander Jones wrote: > Propose adding support for > > let function foo() {}; > > which would have the equivalence of: > > let foo = function foo() {}; > > The idea is to support the normal scoping of let, but w

Re: Subclassing ES6 objects with ES5 syntax.

> > const goodPromises = new WeakSet(); > class DefensivePromise { > constructor(x) { > super(x); > if (new.target === DefensivePromise) { > Object.freeze(this); > goodPromises.add(this); > } > } > static resolve(x) { > if (goodPromises.has(x)) { > return x;

Re: Subclassing ES6 objects with ES5 syntax.

> > Domenic, Kevin: the concern about Reflect.construct seems misplaced, but > in any event, the issue C. Scott raises wants addressing on its own. WDYT? > Yeah, sorry for dwelling on Reflect.construct so much (it's in my mind for other reasons). So what would the ideal Promise.resolve semantics

Re: Subclassing ES6 objects with ES5 syntax.

> > So, ES6 Promises reflect a specific set of design decisions, including a > specific definition of "same type" that appears to exist solely for use by > Promise.resolve. All that design guarantees is that the object has an > certain specific internal slot whose value is tested in a specific way

Re: Merge map values

Another option: var map = new Map; Array.from("mainn") .map(c => c.toLowerCase()) .forEach(c => map.set(c, (map.get(c) | 0) + 1)); This kind of question is probably better left for StackOverflow, however. ___ es-discuss mailing list

Re: Subclassing ES6 objects with ES5 syntax.

> > x = Reflect.construct(Promise, x, C); > > is another fine way to fool someone who wrote "C.resolve(x)" and expected > to get an instance of C back. > Thanks for pointing this out. I believe the ability to use an arbitrary newTarget parameter for Reflect.construct is breaking the intent of Pro

Re: Subclassing ES6 objects with ES5 syntax.

> > I think I'd rather see `Promise.resolve` changed to use `this.constructor` > instead of `this.[[PromiseConstructor]]`, like every other Promise-related > method. Can someone who feels strongly otherwise give me the use case for > `[[PromiseConstructor]]` existing? > I'll give it a shot. "Pro

Re: Existential Operator / Null Propagation Operator

I think it's a good idea to attempt to express these ideas using existing syntax and see what that might look like. So, for a bit of fun, I wrote this: https://gist.github.com/zenparsing/9ff3036b6eb15fa436e4 Basically, there's a Maybe function which returns a proxy over a target, and returns May

Re: super.prop assignment can silently overwrite non-writable properties

> > ``` >> var y = { >> __proto__: x, >> set prop(v) { >> // ... >> super.prop = v; >> } >> }; >> y.prop = 42; >> ``` >> > > Assuming `x` here is the object where "prop" is bound to an accessor, can > you clarify how this would lead to an infinite recursion? > Assu

Re: super.prop assignment can silently overwrite non-writable properties

> > ``` > var parent = {}; > var v = 1; > var x = Object.create(parent, { > prop: { get: function() { return v; }, set: function(n) { v = n; }, > configurable: true } > }); > > Reflect.set(parent, "prop", 2, x); // under Allen's proposed changes, this > will return false while I think it should

Re: super.prop assignment can silently overwrite non-writable properties

> > 5.e If *existingDescriptor* is not *undefined*, then >i. If IsAccessorDescriptor(*existingDescriptor*), return *false*. >ii. If *existingDescriptor*.[[Writable]] is *false*, return > *false*. >iii. Let *valueDesc* be the PropertyDescriptor{[[Value]]: *V*}. >i

Re: Template strings flags

> Why not provide special formatting flags for `Template strings`? > Tagged template strings are your friend. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

  1   2   3   4   5   6   7   8   9   10   >