Re: Proposal: switch statement multiple

On 02/15/2019 08:02 PM, Juan Pablo Garcia wrote: I think it would be great if the switch statement allows multiple argument Example Switch(a,b) Case: 1,true Case: 1,false Case: 2,true You need braces for the switch statement, and the colon goes after the expression; I assume you meant

Re: Proposal: switch statement multiple

https://github.com/tc39/proposal-pattern-matching On Sat, Feb 16, 2019 at 4:02 AM Juan Pablo Garcia wrote: > I think it would be great if the switch statement allows multiple argument > > Example > Switch(a,b) > Case: 1,true > Case: 1,false > Case: 2,true > > > > Switch (true, true) >

Re: Proposal: switch statement multiple

It's being considered, just indirectly through a more powerful feature: https://github.com/tc39/proposal-pattern-matching On Fri, Feb 15, 2019 at 23:02 Juan Pablo Garcia wrote: > I think it would be great if the switch statement allows multiple argument > > Example > Switch(a,b) > Case: 1,true >

Proposal: switch statement multiple

I think it would be great if the switch statement allows multiple argument Example Switch(a,b) Case: 1,true Case: 1,false Case: 2,true Switch (true, true) Case: isPremium, true Case: isBasic, hasCredit Case: isBasic, !hasCredit Maybe case: default, true Look forward to read yours

Re: add stage4 constraint - ease-of-minification

> I just have a copy of npm\node_modules\google-closure-compiler/compiler.jar good to know. also, the previous benchmark was misleading, because terser didn’t mangle by default [1]. with mangling, its performance is inline: ```shell npm install google-closure-compiler terser uglifyjs-lite

Re: Proposal: `Object.isEmpty(value)`

They don't optimize this. Also, in an earlier reply, I mentioned I'm not a fan of that kind of hack, especially considering the obvious `Reflect.ownKeys(x).length === 0` doesn't work when `x` is `null`/`undefined`, while `for ... of` does. -Isiah

Re: Proposal: `Object.isEmpty(value)`

I meant `true` for those - I had my conditions flipped. My bad. - Isiah Meadows cont...@isiahmeadows.com www.isiahmeadows.com On Thu, Feb 14, 2019 at 8:55 AM Andrea Giammarchi wrote: > > > 1. If `value` is either `null` or `undefined`, it gracefully falls back to > > `false` instead of

Re: Proposal: `Object.isEmpty(value)`

> 1. If `value` is either `null` or `undefined`, it gracefully falls back to `false` instead of throwing an error. I am having hard time logically thinking of an empty void as false: Object.isEmpty(void 0) is false ? I think keys(o || {}).length === 0 is a more explicit, ambiguity free,

Re: Proposal: `Object.isEmpty(value)`

On 14. 2. 2019 7:54, Jordan Harband wrote: `Reflect.ownKeys(x || {}).length === 0`? This seems to reify key list. That gist of the OP is probably to be able to be able to tell fast enough if it's empty. Or are JS engines actually doing this fast (like returning "virtual" keys list for

Re: Proposal: `Object.isEmpty(value)`

`Reflect.ownKeys(x || {}).length === 0`? On Wed, Feb 13, 2019 at 10:31 PM Isiah Meadows wrote: > This would be roughly equivalent to `Object.keys(value).length === 0`, > but with a few exceptions: > > 1. If `value` is either `null` or `undefined`, it gracefully falls > back to `false` instead

Proposal: `Object.isEmpty(value)`

This would be roughly equivalent to `Object.keys(value).length === 0`, but with a few exceptions: 1. If `value` is either `null` or `undefined`, it gracefully falls back to `false` instead of throwing an error. 2. It takes enumerable symbols into account, like `Object.assign`. So more

Re: add stage4 constraint - ease-of-minification

On Tue, Feb 12, 2019 at 7:07 PM kai zhu wrote: > npm google-closure-compiler handles transpilation and minifiction. > and it's just 2 deps, itself, and Java. > https://www.npmjs.com/package/google-closure-compiler > > > hmm, google-closure-compiler actually has 29 dependencies (57mb total) > I

Re: add stage4 constraint - ease-of-minification

fyi, i benchmarked minification-performance of google-closure-compiler and terser against a "classic" es5-compiler (uglifyjs-lite). google-closure-compiler is comparable to es5-compiler (but slow to compile), while terser is significantly worse: minifiying jquery-v3.3.1.js uminified:

Re: add stage4 constraint - ease-of-minification

> npm google-closure-compiler handles transpilation and minifiction. > and it's just 2 deps, itself, and Java. > https://www.npmjs.com/package/google-closure-compiler > hmm, google-closure-compiler actually has 29 dependencies (57mb total)

Re: add stage4 constraint - ease-of-minification

I suppose your argument isn't about 'not want to rely on babel' but 'not want to rely on anything'? I don't really understand where you're coming from it's like I missed the first half of the thread... I mean, I abhor babel; it has such huge dependancies. npm google-closure-compiler handles

Re: add stage4 constraint - ease-of-minification

sorry that came out wrong, but i'm generally uncomfortable with the dearth of reliable/correct es6+ compliant minifiers. and i feel its an industry-concern which slows product-development. On Tue, Feb 12, 2019 at 6:35 PM kai zhu wrote: > Yes, exactly. minification-tooling is a real-concern for

Re: add stage4 constraint - ease-of-minification

Yes, exactly. minification-tooling is a real-concern for any consumer-facing javascript-product, and not all of them want to rely on babel. Are you arguing all new javascript-products should be coerced to integrate with babel, because it has a monopoly on such critical-tooling? On Tue, Feb 12,

Re: add stage4 constraint - ease-of-minification

So effectively, you're arguing that stagnant tools should hold back evolution of the language, even when non-stagnant alternatives exist? On Tue, Feb 12, 2019 at 3:26 PM kai zhu wrote: > > Can you expand on what you mean by this, or provide an example of a > > feature that can't be "easily

Re: add stage4 constraint - ease-of-minification

> Can you expand on what you mean by this, or provide an example of a > feature that can't be "easily minified”? fat-arrow/destructuring/es6-classes comes to mind. if you have legacy build-chain that doesn't use babel or terser, is it worth the effort to retool the minifier to support these

Re: add stage4 constraint - ease-of-minification

On Tue, Feb 12, 2019 at 7:44 AM kai zhu wrote: > i think there’s an industry-painpoint (at least from my experience), of > resistance adopting es6+ features because legacy-toolchains cannot be easily > retooled to minify them. > > i’m not sure the best way to address this problem? i favor

add stage4 constraint - ease-of-minification

i think there’s an industry-painpoint (at least from my experience), of resistance adopting es6+ features because legacy-toolchains cannot be easily retooled to minify them. i’m not sure the best way to address this problem? i favor requiring 2 independent minifiers to be able to handle a

Re: New Proposal: Number.range (Yes, range again)

I'm really cheering for the slice-notation range extension proposed in https://github.com/tc39/proposal-slice-notation/issues/19#issuecomment-421453934 ```js for (const i of Number.range(0, 43)) { console.log(i) // 0 to 42 } const fakeData = [...Number.range(1, 21)].map(x => x ** 2) ```

RE: A way to fire logic at the end of completion of the current class method (regardless of super call order).

You can use a Proxy in the base class: let handlerExample = { get(target, prop) { let feature = target[prop] return feature instanceof Function ? function () { console.log('Before call'); let result = feature.apply(this, arguments)

Re: A way to fire logic at the end of completion of the current class method (regardless of super call order).

I presume you've *never* written non-trivial server-side logic in Node. I find myself using classes *far* more often in Node than in the browser simply because it's more than just passing strings and object bags around. You've got caching, process management, and even sometimes task queues. The

Re: A way to fire logic at the end of completion of the current class method (regardless of super call order).

I get that, but it's usually part of the API subclassing contract that the superclass *explicitly* depends on certain parts of the subclass. Abstract classes immediately come to mind, and I'd say it's no more leaking than any inherited method. It's not giving them any more access to information

Re: A way to fire logic at the end of completion of the current class method (regardless of super call order).

If the superclass constructor has a way to run any code after subclass constructors, then implementation details of the *subclasses* are then leaked. On Sat, Feb 9, 2019 at 2:15 AM Isiah Meadows wrote: > I've also had *several* scenarios where I could've used this > personally. I feel ES

Re: A way to fire logic at the end of completion of the current class method (regardless of super call order).

> I feel ES classes are overly restrictive in preventing > this, since it basically forces you to force subclasses to do > something like `this.init()` right after the class is allocated, > leaking implementation details left and right. its not a design-flaw. the flaw is you trying to shoehorn

Re: A way to fire logic at the end of completion of the current class method (regardless of super call order).

I've also had *several* scenarios where I could've used this personally. I feel ES classes are overly restrictive in preventing this, since it basically forces you to force subclasses to do something like `this.init()` right after the class is allocated, leaking implementation details left and

Some Collections methods issues waiting for feedback

I would like to hear feedback from you on certain issues in proposal "collection methods". https://github.com/tc39/proposal-collection-methods/issues/32 - order of method/constructor calling. https://github.com/tc39/proposal-collection-methods/issues/31 - Map.prototype.update combining

A way to fire logic at the end of completion of the current class method (regardless of super call order).

I many times find myself in cases where a base class wants to ensure that logic is always fired after the current method's execution, so that for example no matter in which order sub classes call the `super` method, the `super` method can still guarantee that logic fires after the whole stack of

Re: Promise.resolve

You'll find a solid explanantion here: https://github.com/tc39/ecma262/issues/544#issuecomment-275881668 Array.from, Array.of were designed in very early stage of ES2015, and fact that they work that way (while e.g. Promise.resolve does not), is now considered a mistake that was too late to

Re: Introspect bind function targets

> for (var i = 0; i < 10; i++) { >foo({ handleClick: () => {} }) > } your ux-workflow example of creating multiple, closure-bound handleClick's is wasteful, and more complicated than needs be. the correct design-pattern is to delegate it with a single handClickDelegated (and figure out

Re: Introspect bind function targets

For example given a set of values. A function that checks whether the values of the object are equal could shallow compare the values of each property in the object. However this heuristics falls short for inline/bound functions that share the same target/backing but are only different with

Re: Introspect bind function targets

Given that you can also do `const c = (...args) => proto.call(null, ...args);`, and `Function.isSameTarget(a, c)` would presumably be `false`, can you elaborate more on the use case for this? On Mon, Feb 4, 2019 at 9:38 AM Sultan wrote: > A way to determine if two bound functions reference the

Re: NumberFormat maxSignificantDigits Limit

There is precedence for using numbers around 20 for significant digit cutoffs in the spec. For example, if you look at how number tokens are parsed in the spec (§11.8.3.1), the implementation has the option to ignore significant digits after the 20th. That's not a bug; we did that

Introspect bind function targets

A way to determine if two bound functions reference the same target function. For example: function proto () {} const a = proto.bind(null, 1) const b = proto.bind(null, 2) console.assert(Function.isSameTarget(a, b)) ___ es-discuss mailing list

Re: returning non-Promise values from async functions and running them synchronously (or Promise.sync() idea)

Unfortunately, turning async code (which often has components that execute in a different thread or process) back into in sync code is really, really hard. What semantics would you give to this `Promise.sync()`? Can other code be executed by the main thread while you're waiting for your promise

Re: returning non-Promise values from async functions and running them synchronously (or Promise.sync() idea)

I agree that sometimes-sync is always a nightmare, and I've experienced this pain personally from a library API that once did this. (I did succeed in getting it to eventually change.) I'm willing to draw exception for things like APIs that wrap both sync and async iterators, but those literally

Re: idea: Array.prototype.remove

The proposed `remove` here is actually in-place. And this really is not unlike this proposal of mine [1], which is also in place. The reason it belongs in the standard library is because you can optimize it *way* better using vector instructions and it's among one of the most common cases for

Re: returning non-Promise values from async functions and running them synchronously (or Promise.sync() idea)

Typically, APIs that are sometimes sync and sometimes async are called "z̲̗̼͙̥͚͛͑̏a̦̟̳͋̄̅ͬ̌͒͟ļ̟̉͌ͪ͌̃̚g͔͇̯̜ͬ̒́o̢̹ͧͥͪͬ" - unpredictable, hard to maintain, hard to understand. The general best practice is that a function should always be async, or always sync, but never the twain shall meet.

Re: idea: Array.prototype.remove

Why "remove" and not `.filter`, to produce a new array? On Sun, Feb 3, 2019 at 9:56 PM #!/JoePea wrote: > I sometimes find myself doing things like > > ```js > this.children.splice(this.children.indexOf(child), 1) > ``` > > but it seems that it will iterate the array twice. Maybe a new method

idea: Array.prototype.remove

I sometimes find myself doing things like ```js this.children.splice(this.children.indexOf(child), 1) ``` but it seems that it will iterate the array twice. Maybe a new method can be introduced so engines can optimize it: ```js this.children.remove(child) // or

Re: returning non-Promise values from async functions and running them synchronously (or Promise.sync() idea)

You could move the async part into a helper function and call that from a sync function you instead expose. I've used this trick more than once, and although it is a bit of boilerplate, it works well enough. On Sun, Feb 3, 2019 at 18:40 #!/JoePea wrote: > I often find myself enjoying async

Re: Promise.resolve

It is the valid answer, subclassing is the reason behind the design choice of Promise static members depending on `this`. If it was a good decision or not is another topic. `Array.of` was designed in a different occasion and static methods inheritance was not a subject at the time Em dom, 3 de

Re: Promise.resolve

This is not valid answer. Arrays can be subclassed too, but (1,Array.of)(2,3 ) returns instance of Array. On Sat, Feb 2, 2019 at 10:20 PM Logan Smyth wrote: > `Promise` can be subclassed, so the `this` context for `resolve` affects > what class is instantiated. > > On Sat, Feb 2, 2019 at 12:25

returning non-Promise values from async functions and running them synchronously (or Promise.sync() idea)

I often find myself enjoying async functions until the time comes when I don't want to await anything, and I want the call stack to be sync (i.e. I don't want to defer if I don't have to). But, async functions always return a Promise. So I find my self converting my async functions back into

Re: Named factory functions

I suspect that would break a ton of code - ES6 name inference already broke some of mine, but I was able to work around it by using this kind of indirection. On Sun, Feb 3, 2019 at 11:02 AM Sultan wrote: > Where there any attempts to allow factory functions the ability to assume > the name of

Named factory functions

Where there any attempts to allow factory functions the ability to assume the name of the binding they are assigned to? Consider the following: function factory () { return function () {} } var foo = factory() console.assert(foo.name === 'foo') ___

Re: Promise.resolve

`Promise` can be subclassed, so the `this` context for `resolve` affects what class is instantiated. On Sat, Feb 2, 2019 at 12:25 PM Sultan wrote: > Was there any reason Promise.resolve was not afforded the ability to > dispatch outside of `this` pointing to the `Promise` constructor? > > For

Promise.resolve

Was there any reason Promise.resolve was not afforded the ability to dispatch outside of `this` pointing to the `Promise` constructor? For example: const {resolve} = Promise resolve(1234) This currently throws. ___ es-discuss mailing list

Re: Dash-case keys

On Tue, Jan 29, 2019 at 7:45 AM Sultan Tarimo wrote: > That is obj.font-size would rightly be invalid. By which I think you mean, would still be `obj.font - size` with its current meaning. I don't think the confusion that causes is worth the benefit of not putting the name in quotes in the

Re: Dash-case keys

There's a difference, though, between private field access - an entirely distinct and new kind of thing - and normal property access, a well-established and understood thing. On Mon, Jan 28, 2019 at 11:53 PM Sultan Tarimo wrote: > This is expected and by design. For example

Re: Dash-case keys

This is expected and by design. For example obj[‘#invalidPrivateSigil’] is also not invalid. The affordances would be the same. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Dash-case keys

> Le 29 janv. 2019 à 08:45, Sultan Tarimo a écrit : > > That is obj.font-size would rightly be invalid. Sadly, `obj.font-size` is *not* invalid, it has some well-defined semantics. That would be a source of bugs —Claude___ es-discuss mailing

Re: Dash-case keys

That might have been the case, but the expectation that an unquoted form should equally have a quoted form or vice-versa is not an issue in practice given the presence of a similar but opposite semantic in the private sigil access notation proposal: object.#validPrivateSigil ->

Re: Dash-case keys

i think if i can use something unquoted in an object literal, i'd expect to be able to use it in dot access - ie, `obj.font-size` - and then that problem arises. On Mon, Jan 28, 2019 at 3:43 PM Sultan Tarimo wrote: > The former as the following is equally invalid syntax errors: > > const font =

Re: Dash-case keys

The former as the following is equally invalid syntax errors: const font = 1 const size = 1 const a = { font-size: 10 } const b = { font+size: 10 } ___ es-discuss mailing list es-discuss@mozilla.org

Re: Dash-case keys

is that a key called "font-size" or the subtraction of `size` from `font`? On Mon, Jan 28, 2019 at 1:48 PM Sultan wrote: > Is there any reason that dash-case keys are not supported in the object > literal syntax. > > For example: > > const style = { > font-size: 10 > } > > Compared to what

Dash-case keys

Is there any reason that dash-case keys are not supported in the object literal syntax. For example: const style = { font-size: 10 } Compared to what one needs to do today: const style = { 'font-size': 10 } ___ es-discuss mailing list

Re: Proposal: Default object method

Yeah! The static version of this is definitely something I see as a natural next step. From my observation, tc39 proposals seem to take on the instance and static versions of a feature separately. So for that reason it wasn’t mentioned. But yes, if this proposal somehow made it through the

Re: Proposal: Default object method

Thank you all so much for the feedback! The push-back has given me something to more to consider. I’d like to add a couple points which are hopefully clarifying, but I do acknowledge the idea doesn’t seem to be attracting positive interest in its current form. I meant to note in the original

Re: Proposal: Default object method

Isiah: good find. I was just being sloppy to get the idea across. J. Decker: The code I gave was just an example of how to do it if it was for some reason absolutely necessary to use `class`. I don't see the need and would either tend toward your approach, or just somehow refactor away the need

Re: Proposal: Default object method

On Sun, Jan 27, 2019 at 10:46 PM Ranando King wrote: > Jordan's right. This one is best handled by a function. But if there is > some reason you need to create callable objects, it's still doable, even > with ES as-is. Just extend your classes from something like this: > > ```js > class Callable

Re: Proposal: Default object method

Nit: you may need to reset the function's prototype. Also, `create` should probably be static. ;-) On Mon, Jan 28, 2019 at 01:46 Ranando King wrote: > Jordan's right. This one is best handled by a function. But if there is > some reason you need to create callable objects, it's still doable,

RE: Proposal: Default object method

There’s nothing in that proposal says that an object with a `Symbol.apply` has to have a different `typeof`. It *would* mean that any Call might require additional dispatch which could have performance implications. It could also be an approach to support “callable” classes: ```js class Foo {

Re: Proposal: Default object method

Jordan's right. This one is best handled by a function. But if there is some reason you need to create callable objects, it's still doable, even with ES as-is. Just extend your classes from something like this: ```js class Callable { constructor(defaultFn) { return (...args) => { return

Re: Proposal: Default object method

Something that can be invoked has a `[[Call]]` slot, and is `typeof` "function". Adding a Symbol that makes something callable would have a number of effects - it would make `typeof` (one of the most robust operations in the language) unsafe, because it would have to access the Symbol method,

Proposal: Default object method

Apologies if this has been raised before. I was unable to locate anything similar. Any thoughts or ideas on this proposal would be appreciated! Original: https://gist.github.com/brasten/f87b9bb470973dd5ee9de0760f1c81c7

Re: Native Assertions

Good to know that has moved forward, but it is still minimally relevant due to the other points raised. Also as an FYI the following paper from OOPSLA 2018: Collapsible Contracts: Fixing a Pathology of Gradual Typing https://www.eecs.northwestern.edu/~robby/pubs/papers/oopsla2018-fgsfs.pdf

Re: Native Assertions

console.assert is standardized by the WHATWG at https://console.spec.whatwg.org/#assert. Sebastian On Mon, 14 Jan 2019 at 12:39, Michael Haufe wrote: > console.assert is not standardized at this point, nor is it part of the > language. Additionally, the semantics are inappropriate for the

Re: NumberFormat maxSignificantDigits Limit

Here's a wikipedia link for what it's worth. https://en.wikipedia.org/wiki/Extended_precision Look at the *Working Range* section. On Sat, Jan 26, 2019 at 2:03 PM Ranando King wrote: > There's another possibility. C++ was the language of choice back then. It > had a type "long double", a

Re: NumberFormat maxSignificantDigits Limit

There's another possibility. C++ was the language of choice back then. It had a type "long double", a 80-bit extended double type. It was meant to match Intel's implementation of IEEE 754. This number format can be safely and reversibly converted back and forth with 21 significant digits. On Thu,

Re: Discussion: Module Reflection - import.reflect

In `import * as m from myModule`, `m.default` is already the default export; `Object.keys(m)` is already the list of export names, and `Object.entries(m).filter(([k, v]) => typeof v === 'function'))` is the list of functions. On Fri, Jan 25, 2019 at 5:27 AM Randy Buchholz wrote: > Would it be

Discussion: Module Reflection - import.reflect

Would it be worthwhile to add reflection to modules as a distinct feature? `import.meta.url` is a basic form of reflection, but it seems (?) `meta` is trying to be a fairly loose specification. Being able query a module can be helpful. For example, if I can see the static imports, I can

Re: NumberFormat maxSignificantDigits Limit

For all here interested, you might want to follow this Twitter conversation I started. My theory is a subtle spec bug that copied the number instead of recalculating the formula. https://twitter.com/isiahmeadows1/status/108851744948878 - Isiah Meadows cont...@isiahmeadows.com

Re: NumberFormat maxSignificantDigits Limit

On 2019-01-24 04:45, Ethan Resnick wrote: Well, if you remove the trailing 0s you get an entirely different number.  That's pretty significant. Note that this is the default ES serialization as well. This makes no sense to me. Yes, removing trailing 0s, and therefore changing the

Re: NumberFormat maxSignificantDigits Limit

> > Well, if you remove the trailing 0s you get an entirely different number. > That's pretty significant. > Note that this is the default ES serialization as well. > This makes no sense to me. Yes, removing trailing 0s, and therefore changing the magnitude of the number, changes its meaning. But

Re: PSA: You can find existing proposals at https://github.com/tc39/proposals

On Sun, Jan 20, 2019 at 11:05 PM Frederick Stark wrote: > > There's also https://prop-tc39.now.sh/... (Interested, he clicks link.) > ...which is much more readable. (Recoiling, he reminds himself that "more readable" is a **deeply** subjective concept. ;-) ) -- T.J. Crowder

Re: NumberFormat maxSignificantDigits Limit

On 2019-01-21 07:14, Carsten Bormann wrote: On Jan 21, 2019, at 07:03, Anders Rundgren wrote: coming IETF standard We don’t know that yet. Right, but it looks rather promising in addition to being verified to work on multiple platforms. The days of the Base64Url tyranny are numbered

Re: NumberFormat maxSignificantDigits Limit

This limit seems a bit strange though: console.log(new Intl.NumberFormat('en', { maximumFractionDigits: 20 }).format(-0.03)); Result: -0.0333 That's actually two digits less than produced by the default ES serialization. "maximumFractionDigits" is limited

Re: NumberFormat maxSignificantDigits Limit

On Jan 21, 2019, at 07:03, Anders Rundgren wrote: > > coming IETF standard We don’t know that yet. Grüße, Carsten ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: NumberFormat maxSignificantDigits Limit

On 2019-01-21 06:54, Ethan Resnick wrote: if you input this in a browser debugger it will indeed respond with the same 21 [sort of] significant digits 0 I'm pretty sure the 0s don't count as significant digits (and,

Re: NumberFormat maxSignificantDigits Limit

> > if you input this in a browser debugger it will indeed respond with the > same 21 [sort of] significant digits > 0 I'm pretty sure the 0s don't count as significant digits (and, with floating point numbers, it makes sense

Re: PSA: You can find existing proposals at https://github.com/tc39/proposals

There's also https://prop-tc39.now.sh/, which is much more readable. It generates it's content by scraping the GitHub pages, so should usually be up to date On Jan 20 2019, at 12:35 pm, Isiah Meadows wrote: > Not TC39, so don't read this as official communication. > > I've lately been seeing

Re: NumberFormat maxSignificantDigits Limit

It does seem unclear why the limit is 21. Is that maybe the most you need to uniquely stringify any double value? > an only encode up to 17 significant decimal digits That's true for decimal values, but the limit of 21 would also include the fractional portion of the double value as well, so

Re: NumberFormat maxSignificantDigits Limit

I feel this is probably best asked at https://github.com/tc39/ecma402, since it seems to imply a potential spec bug. - Isiah Meadows cont...@isiahmeadows.com www.isiahmeadows.com On Sun, Jan 20, 2019 at 2:31 PM Anders Rundgren < anders.rundgren@gmail.com> wrote: > On 2019-01-20 20:18,

Re: NumberFormat maxSignificantDigits Limit

On 2019-01-20 20:18, Ethan Resnick wrote: Hi, Apologies if es-discuss is the wrong venue for this; I've tried first poring through the specs and asking online to no avail. My question is: why is the limit for the `maximumSignificantDigits` option in the `NumberFormat` API set at 21? This

NumberFormat maxSignificantDigits Limit

Hi, Apologies if es-discuss is the wrong venue for this; I've tried first poring through the specs and asking online to no avail. My question is: why is the limit for the `maximumSignificantDigits` option in the `NumberFormat` API set at 21? This seems rather arbitrary — and especially odd to me

Re: Re: Proposal: enhanced case clause

Good Idea, thank you for answer, I will do it :) 2019년 1월 20일 (일) 오후 6:01에 Isiah Meadows 님이 작성: > I'd say the best way is to just file an issue. > > - > > Isiah Meadows > cont...@isiahmeadows.com > www.isiahmeadows.com > > > On Sun, Jan 20, 2019 at 3:59 AM Sm In wrote: > >> Thank you for

Re: Re: Proposal: enhanced case clause

I'd say the best way is to just file an issue. - Isiah Meadows cont...@isiahmeadows.com www.isiahmeadows.com On Sun, Jan 20, 2019 at 3:59 AM Sm In wrote: > Thank you for answer, I've checked thart proposal before. > As I know, proposal-pattern-matching contains guards(which checkes

Re: Re: Proposal: enhanced case clause

Thank you for answer, I've checked thart proposal before. As I know, proposal-pattern-matching contains guards(which checkes value's property) Yes, this proposal's new sementic seems duplicate pattern match's guard. But, As I know, the guard can be associcated with only one pattern. here is an

Re: es-discuss Digest, Vol 143, Issue 41

Please unsubscribes me On Sun, 20 Jan 2019 at 12:40 PM, wrote: > Send es-discuss mailing list submissions to > es-discuss@mozilla.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mail.mozilla.org/listinfo/es-discuss > or, via email, send a message with

Re: RegExp.prototype.count

+1 for string.count i don’t think the g-flag is necessary in str.split, so the original performance claims are still valid: - for counting regexp - use split + length - for counting substring - use while + indexOf > On 20 Jan 2019, at 12:22 AM, Isiah Meadows wrote: > > Nit: you should use

Re: RegExp.prototype.count

Nit: you should use `.spilt(/\n/g)` to get all parts. I like the benchmarks here. That's much appreciated, and after further investigation, I found a *giant* WTF: https://jsperf.com/regexp-counting-2/8 TL;DR: for string character counting, prefer `indexOf`. For similar reasons to that JSPerf

Re: RegExp.prototype.count

benchmarked @isiah’s while-loop test-case vs str.split vs str.replace for regexp counting on jsperf.com [1], and the results were surprising (for me). benchmarks using 1mb random ascii-string from fastest to slowest. 1. (fastest - 1,700 runs/sec) regexp-counting with

PSA: You can find existing proposals at https://github.com/tc39/proposals

Not TC39, so don't read this as official communication. I've lately been seeing the occasional suggestion that's already been considered by TC39 and accepted, so I just wanted to give a public service announcement that you can find all the various existing proposals TC39 has considered (Stage

Re: Proposal: enhanced case clause

Rather than investing more in switch statements, https://github.com/tc39/proposal-pattern-matching may be more compelling :-) On Sat, Jan 19, 2019 at 11:23 AM Sm In wrote: > *Before read: I'm not a native. so I may used some unnatural expression, > or non-sense sentence. I feel so sorry for

Proposal: enhanced case clause

*Before read: I'm not a native. so I may used some unnatural expression, or non-sense sentence. I feel so sorry for this. :(* ## preface currently, a switch statements's case claues compares equality between it's value and the switch statements's input value. just like this: ```js switch(x) {

Re: Proposal: [Symbol.equals]

As has been stated many times before, many JS developers have been hired to do things entirely unrelated to UX workflows; regardless, whether you like a specific coding style or not is *irrelevant* to discussing language features, and is very disruptive to these discussions. Please confine that to

Re: Proposal: [Symbol.equals]

> This thread would apply equally well to objects (there's no such thing as a > "json object" - json is a string, and once it's parsed into an object it's > not json anymore) as to classes. i’m not so sure when you start having classes with getters/setters/private-fields. then people begin

<    8   9   10   11   12   13   14   15   16   17   >