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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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"

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 >

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

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

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

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

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

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 } >

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

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

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

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

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? >

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) => {

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 <zenpars...@gmail.com> wrote: > Is there a reason to use a Promise as the cancellation token, rather than >> have something that is synchronously inspectable? >> >

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

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

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 () { >

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 > } > ``` >

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 >

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

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

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

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

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 >

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

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

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

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

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

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 all use

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: 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

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

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:

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-discuss

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 always just

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: what

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 tinga...@gmail.com wrote: Just following a discussion we had on

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

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

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

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?

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: 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

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

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 designs for

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 mailing

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 object

Re: Language design

https://i.imgflip.com/mtot6.jpg On Fri, Jun 12, 2015 at 6:55 PM KOLANICH kola...@mail.ru 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

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, invoke

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? 2.

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

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 prototype

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 are

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 initializers outside

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

Hi Logan - that's correct. On Tue, Jun 2, 2015 at 11:08 PM Logan Smyth loganfsm...@gmail.com 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

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 where let

Re: let function

Why not use a function declaration instead? On Thu, May 14, 2015 at 2:37 PM Alexander Jones a...@weej.com 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,

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 a...@weej.com wrote: In Python, sending a value other than `None` into the first invocation of `send` raises an error. That seems

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; // should

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 by

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.

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 do?

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

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.

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

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? Assume let x = {}; (i.e. no

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 just call

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*}. iv.

Re: Putting `global` reference in specs

We have `self` in DOM land too, so you can consistently use `self` across Window and Workers. Why didn't I know this!? Cool : ) and `global` in most common server side JS engines Sounds like they should add `self`. ;) That would make sense.

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

Re: Existential Operator / Null Propagation Operator

Plus, it can be used for normalizing null/undefined to undefined: var normalizedFoo = ?foo; Seems sort of nice that it is separated and there are no special operations for ?., ?(, ?[. I agree, that is nice. But how does Nil get transformed into undefined?

Re: Existential Operator / Null Propagation Operator

If we can come to an agreement on the existential operator for member expressions, we would also be setting a precedent for other features of the same family. For example, existential call expressions: `fn?()` which would conditionally invoke `fn`. In the meeting notes you linked to,

Re: this value inside anonymous generator

Generator arrows are a possibility, but we need to see how the use cases develop in practice. For the specific use case in the OP, async arrows would actually be a better fit. ___ es-discuss mailing list es-discuss@mozilla.org

  1   2   3   4   5   6   7   8   9   10   >