Re: syntax for case ranges

Yes, there have been numerous backwards-incompatible changes to the language over the years. You can find a list of them in section E of the ECMAScript language standard. IIRC, that list is non-exhaustive. On Monday, February 3, 2020 6:35:12 PM CET Naveen Chawla wrote: > Thank you Claude! I

Re: Optional Curly Braces in JavaScript

@Bergi: Thanks. This is true only as long as the semantics of significant- whitespace blocks are supposed to stay exactly the same as the semantics of braced blocks. If this proposal is purely syntactical, you are right, but then, I would fail to see the point of this endeavor. @Ed: Maybe

Re: Optional Curly Braces in JavaScript

Note that significant whitespace greatly minimizes the yields of minification as well, which doesn't matter much for languages like Python, but starts to matter as soon as you're forced to send your source code over the network, expecting something to appear on the screen in a few hundred

Re: Modulo Operator %%

Reply inline. On Friday, August 16, 2019 5:50:40 PM CEST peter miller wrote: > Hi, > > +1 for _at_least_ having `Math.mod()` > > And here's a reason why: > > The code `mod = (x,y) => ( ( x % y ) + y ) % y` is not only slow but > inaccurate. For example, for `mod( -24982515569.97, >

Re: Modulo Operator %%

We could circumvent this by making `%%` analogous to `**`. That is, we could provide a function form `Math.mod` as well as an infix operator `%%`. On Thursday, August 15, 2019 9:46:57 AM CEST Andrea Giammarchi wrote: > FWIW another disadvantage is that operators cannot be polyfilled, so it'll >

Re: Modulo Operator %%

I would welcome such an operator as well. I find myself implementing a `mod` function from time to time, expressing it in terms of the remainder operator. As for syntax, I don't see `%%` posing any syntactical ambiguities, so I'll second it. On Monday, August 12, 2019 10:00:09 PM CEST Matthew

Re: Proposal: `String.prototype.codePointCount`

So what's wrong with `Array.from(str).length`? On Thursday, August 8, 2019 4:37:07 AM CEST fanerge wrote: > I expect to be able to add an attribute to String.prototype that returns the > number of codePoints of the string to reflect the actual number of > characters instead of the code unit. >

Re: strawman proposal for base4 and base 32 integer literals

Sorry, but I highly doubt that it's worth reserving syntax for two bases for which even the author suggests their lesser usefulness. This is best kept in user-space. Base-4 numbers should already be covered by this[1] proposal. As for base 32, Carsten has already pointed out the problem of

Re: Proposal: defer keyword

So, when is a function supposed to be invoked when `defer`red in a generator? On Thursday, September 20, 2018 11:21:06 AM CEST Ayush Gupta wrote: > Hi, > > I would like to propose a `defer` keyword(or something else as the keyword > name) which would allow us to "defer" a function which will

Destructuring instances with private fields

Often times, when I use a class field a lot, I create a local binding for it, so that I don't have to prefix every appearance with `this.`: ```js class Foo { bar = 1; method() { const { bar } = this; /* … */ } } ``` The same approach would

"Redacted"

I'd be interested to learn why it was decided to redact a possible new name for `global` in the latest meeting notes[1]. Although I do understand that redacting the name minimizes its chance to gain more usage, I doubt that the impact would be significant; if anything, I think people would

Re: Proposal static type constraints features

`x = void([Number, mod.BigNumber])` is already valid syntax in ECMAScript, and you can't change its semantics willy-nilly. How do you guarantee that those who have used `void` in their code in the past don't suddenly see unexpected type errors? Also, can you make an example of how you could

Re: Proposal: Phase-Invariant Einno Soliton Templates

To me, what you're actually seeking to discuss looks less related to physics and more like an extension to ECMAScript's `import` syntax. Would you please describe it a little more? A good conversation starter, preferably without any domain-specific context (i.e. physics), would entail: - the

Re: Adding .map() directly to String prototype

Yeah; I am aware that ES2015 added measures that make it possible iterate over codepoints, but that was not quite my point. The problem that I see is that in some scenarios it makes sense to think of a string as an array of bytes, and sometimes you need to iterate over a string in terms of its

Re: Adding .map() directly to String prototype

This idea comes from a rather ASCII-centric perspective upon strings and will definitely break multi-byte characters. And even if it wouldn't, your intent might have been to do just that. Long story short, it's debatable what exactly you want to iterate in a string, hence such a method would

Re: Proposal: Add a global Infinitesimal property

mething like `Number.EPSILON`, but relative to `0` instead of > `1`? > > On Sat, May 12, 2018 at 9:57 AM, kdex <k...@kdex.de> wrote: > > Already available, just prepend a minus sign like so: > > > > ```js > > -Number.MIN_VALUE > > ``` > > > &

Re: Proposal: Add a global Infinitesimal property

A good place to start is [1]. [1] https://github.com/tc39/proposals On Saturday, May 12, 2018 7:11:36 PM CEST Abdul Shabazz wrote: > I wasn't aware of the committees view of synonyms and that they perceive > them ad clutter. This unfortunate but i will moderate my future suggestions >

Re: Proposal: Add a global Infinitesimal property

Already available, just prepend a minus sign like so: ```js -Number.MIN_VALUE ``` Yours would be much longer to type and brings no additional value. On Saturday, May 12, 2018 6:54:42 PM CEST Abdul Shabazz wrote: > Ok. How about Number.NEGATIVE_MIN_VALUE signature.asc Description: This is a

Re: Proposal: Add a global Infinitesimal property

`Number.MIN_VALUE` already exists. On Saturday, May 12, 2018 6:49:32 PM CEST Abdul Shabazz wrote: > As polar opposite to Infinity, Number.POSITIVE_INFINITY, the Infinitesimal > should be a smallest representable value greater than 0. Perhaps someone > else could propose why this would be useful.

Re: Proposal: Allow Symbols behavior to treat entire Array as 1-instance variables

Well, if we really want to delve into linguistics, it's more the opposite of what you're describing: Tons of languages have grammatical features that make English one of the most nondescriptive and ambiguous languages out there: Grammatical cases and gender, a wider variety of tenses, moods,

Re: Proposal: Allow Symbols behavior to treat entire Array as 1-instance variables

"I have no idea why this is useful" is a non-starter. On Friday, May 11, 2018 7:58:55 PM CEST Abdul Shabazz wrote: > Similar to Matlabs operations on sets > > Example 1: > > let a=[1,2,...]; > let b="I have ${a} apples now"; // b=["I have 1 apples now ", "I have 2 > apples now",...] > > >

Re: add reverse() method to strings

If more than one type of reversal makes sense, are there any good reasons against covering this by an optional `mode` argument? This approach would be analogous to `String.prototype.normalize`. On Sunday, March 18, 2018 9:38:18 PM CET Mathias Bynens wrote: > For arrays, indexing is unambiguous:

Re: Proposal to add symbol: "hasInstanceStrict"

Can you give some reasons why this, as opposed to static type checking, is worth pursuing at all? On Sunday, February 18, 2018 5:30:42 PM CET Aleksander Efremov wrote: > It’s attempt to provide intermediate layer for implementation of runtime > type checking. > > ``` > class PrimitiveNumber { >

Re: Async Class

Having the constructor return a `Promise` is generally considered bad practice, since it breaks `new X instanceof X`, which in general breaks inheritance. So, for this idea to work, you really shouldn't mark `constructor` as `async` (since this might suggest it returning a `Promise`, which it

Re: New operator

Please do some research before posting in the future. [1] https://esdiscuss.org/topic/or-equal-operator [2] https://esdiscuss.org/topic/proposing-a-conditional-assignment-or-equals-operator [3] https://esdiscuss.org/topic/new-assignment-operators-not-bit-wise-or [4]

Re: Suggestion: Infix operators/functions

People in the C++ community have been using overloaded operators since the 1980's, and I wouldn't say that different semantics for the same operator have been a bad idea at all, given that the operator handles completely different types (that can and should be statically analyzable). I

Re: Suggestion: Infix operators/functions

In ECMAScript's current state, infix operators would likely complicate future discussions of operator overloading. Before we tackle these problems, I think it's more convenient to have type annotations first. On Friday, February 2, 2018 12:55:17 PM CET Thomas Grainger wrote: > I'm porting this

Re: Allow any quoted string to be multiline?

Another place where this is used particularly often is when dynamically constructing the source for WebGL shaders in the same

Re: Allow any quoted string to be multiline?

t;real-world > > example" for escaping, and to spare us the attachments? > > it may not be relevant to some who can afford to wait a few years for tc39 > to come up with something. but it is relevant to engineers and pm’s with > hard contract deadlines, and need practical

Re: Allow any quoted string to be multiline?

d be > accurate to what I meant. ;-)) > - > > Isiah Meadows > m...@isiahmeadows.com > > Looking for web consulting? Or a new website? > Send me an email and we can get started. > www.isiahmeadows.com > > On Fri, Dec 15, 2017 at 8:53 AM, kdex <k...@kdex.d

Re: Allow any quoted string to be multiline?

Sorry to be pedantic here, but: ```js "this\ right\ here" ``` aren't escaped newlines; that would be "\n". Those up there are line continuations. :) On Friday, December 15, 2017 2:48:00 PM CET Isiah Meadows wrote: > There are ES5 newline escapes. However, it'd be nice if I didn't have > to

Re: Identifying pure (or "pure within a scope") JavaScript functions?

So… is the following function pure? let env = 1; function tryMe() { if (false) { env = 2; } } On Thursday, December 7, 2017 5:22:37 PM CET Alex Vincent wrote: > TLDR: I'm asking for the group to consider adding a Function.isPure(func) > or isPureWithinScope() to

Re: javascript vision thing

I apologize for my ignorance, but I've been seeing this thread in my inbox for around a month now, and most of what's being discussed is just people glorifying ES5 and other people justifying the usefulness of recent language additions. This discussion has gone way off-topic and appears to be

Re: Allow specify numbers with suffixes

Please see [1]. [1] https://github.com/littledan/proposal-extensible-numeric-literals On Thursday, November 23, 2017 2:16:44 PM CET Andrey Muzalevsky wrote: > Idea is simple, also is simple to implement and do not conflicting with > existing standard > > Readability of javascript can be

Re: Consider date formatting

eat > to format it "localized", but if you have strict requirements in your > projects, then you have to build it up yourself or use a library. So I > do not see, how to use Intl.DateTimeFormat for custom format strings. > > On 21.09.2017 08:45, kdex wrote: > > So wha

Re: Consider date formatting

So what's wrong with Intl.DateTimeFormat? On Thursday, September 21, 2017 8:41:33 AM CEST Michael Kriegel wrote: > I would like to suggest to take up date formatting into the standard. > Either as optional format parameter on Date.prototype.toDateString() or > as a separate method

Re: Make comma at the end of line optional

I'm not sure how your text editor is set up, but you may or may not be able to tell soft-wrapping apart from an actual EOL character if you have long lines. I don't like the idea of making whitespace of any kind significant, which is why I would agree with Jordan. On Tuesday, September 12,

Re: Mixing grammars

Ah, I see where you're coming from now. Thanks for the clarification! There has recently been some discussion about the semantics of `|>` in [1]. I think what you're looking for is [2], perhaps? [1] https://github.com/tc39/proposal-pipeline-operator/issues/50 [2]

Re: Mixing grammars

Sorry, but your message looks very opinionated and I can't seem to find any objective reasoning in there. Would you be willing to discuss what exactly you consider the repercussions to be? Many functional languages allow function chaining, some even with a similar syntax. F# features pipe

Re: Lazy evaluation

Just so that there is no confusion: There's also function expression decorators and method parameter decorators, both of which stage 0. On Friday, September 1, 2017 9:16:55 AM CEST Michał Wadas wrote: > Stage 2, but they move really slow. > > On 1 Sep 2017 9:15 am, "Andrea Giammarchi"

Re: Are objects values?

On Saturday, August 19, 2017 8:44:08 PM CEST Naveen Chawla wrote: > But references are also values. It's not a mutually exclusive thing > > On Sat, 19 Aug 2017, 11:32 p.m. kdex <k...@kdex.de> wrote: > > Yes, objects/functions are values, but they are not *primitive

Re: Are objects values?

Yes, objects/functions are values, but they are not *primitive* values. The current draft uses the phrasing "object value" several times. Section 4.3.3 explains that objects are "members of type Object", and a type is, by definition, a set of values. Therefore, objects must be values. On

Re: import.meta and TC39 process as a whole

Neither should emails have that. Please refer to [1] in the future. Thank you! [1] https://mail.mozilla.org/pipermail/es-discuss/2017-July/048584.html On Saturday, August 5, 2017 6:35:19 PM CEST Dmitrii Dimandt wrote: > Too bad emails don’t have "thumbs up" and “+1”s :) So here’s my "+1” to you

Re: Array.prototype.toObjectByProperty( element=>element.property )

Inline. On Saturday, August 5, 2017 1:35:35 PM CEST T.J. Crowder wrote: > On Sat, Aug 5, 2017 at 11:18 AM, Naveen Chawla > > wrote: > > I've often needed to cache array elements by a unique key each > > element has, for quick access. > > Yes, please. I've needed this in

Re: Array findLast() and findLastIndex()

I'm thinking that this may have performance benefits. The naïve approach would be something like: ```js function findLast(array, fn) { return array.reverse().find(fn); } ``` Note that this requires a reversed copy of `array` to reside in memory before `find` can be run, which is not a

Re: Support underscores in numbers

See [1]. [1] https://github.com/tc39/proposal-numeric-separator On Wednesday, July 26, 2017 10:47:27 PM CEST Alexander Craggs wrote: > Large number are hard to read in JavaScript, is 2384923842 over a billion? > Or just several hundred million. One solution to this some languages have > used

Re: Migrating to a better communication tool

I personally wouldn't mind using a forum instead. Another downside of this mailing list is that it doesn't really play nice with DKIM/DMARC, at least in my experience. On Wednesday, July 26, 2017 6:00:16 AM CEST Alexander Craggs wrote: > Thought I'd move the topic of a new communication tool to

Re: Removal of language features

This was kind of the original idea around Dart IIRC. It didn't see much traction though, and eventually got called off. On Monday, July 24, 2017 1:56:53 AM CEST doodad-js Admin wrote: > And more, engines could signal they support JS 2 just by the Accept header! > > -Original Message- >

Re: JavaScript Versioning

For the sake of keeping our discussions clear, could we all please refrain from flooding the entire mailing list's inbox with these unsubstantial "+1" or "-1" emails if they contain no meaningful contribution to the conversation? If you want to make a point, make your point. If not, don't.

Re: Removal of language features

Inline. On Saturday, July 22, 2017 7:47:32 AM CEST Bob Myers wrote: > Let me weigh in as an Angular programmer. > > Angular does not "encourage use of non-standard and/or unstable language > features". It encourages (indeed for all practical purposes mandates) the > use of TypeScript, which like

Re: Operator overloading proposal

Your README.md reads: > Where an operator is used with two operands of the *same type*, […] How would a binary operator work with operands of *different* type (by which I assume we mean its constructor)? On Friday, July 14, 2017 12:22:25 AM CEST Keith Cirkel wrote: > Hello all! > > While I am

Re: Syntax for non-writability and non-configurability

What about non-enumerability? If we had a new token for each combination of { non-writable, non-configurable, non-enumerable }, there would have to be seven new tokens. I'm sure I'm not the only one who'd expect some confusion. Yes, keeping things brief is nice, but I'm not seeing a clear

Re: Roman numeral support in Number type

There's numerous problems with this approach. While ```js new Intl.NumberFormat("it-u-nu-roman").format(100035); ``` procudes "ↈXXXV", ```js new Intl.NumberFormat("it-u-nu-roman").format(100035000); ``` produces "100.035.000". Turns out the largest representable number is 39, but this

Re: Roman numeral support in Number type

Oh, wow. Sorry, but I don't see this happening any time soon. Here's just a few problems: - Roman numerals are hardly ever used. - `0` does not have a standard representation. - Fraction representation is possible, but relatively complicated. - The set of characters used for Roman numerals is

Re: Block scoped prototype extensions

extends Array {}; Array as MyArray; const array = [1, 2, 3]; assert(array instanceof MyArray); ``` On Wednesday, July 5, 2017 8:47:53 PM CEST kdex wrote: > Overriding literals with a derived class is an entirely different problem. > :) > On Wednesday, July 5, 2017 8:42:39 PM CEST Boris Che

Re: Block scoped prototype extensions

Overriding literals with a derived class is an entirely different problem. :) On Wednesday, July 5, 2017 8:42:39 PM CEST Boris Cherny wrote: > I tried that approach, but it doesn’t work when creating objects via literal > notation ([], {}). A bit clumsy to have to write “new Array(1,2,3)", or >

Re: Block scoped prototype extensions

One way to solve this might currently include extending `Array` and overriding`indexOf` in a derived class to reflect the `Option` behavior you're after. On Wednesday, July 5, 2017 8:10:05 PM CEST Boris Cherny wrote: > Hey guys, > > What would it take to get block scoped prototype extensions

Re: are there metrics on how es6 and future proposals affect javascript load-time for webpages?

hidden options of`Experiments`. On Friday, June 23, 2017 6:19:20 AM CEST kdex wrote: > > > First of all, ECMAScript requires an environment, which may or may not > > > be > > > a browser. So it might not necessarily make sense to assume "web pages" > > > or > &

Re: are there metrics on how es6 and future proposals affect javascript load-time for webpages?

e-and-compile jquery vs 2) browser-version-history for > desktop chrome and firefox since 2015? > > Anything else [compile-time] is mostly implementation- > > specific and thus varies from engine to engine. > > yes, relevant proposals should consider the implementation-specific > c

Re: Math.sincos(x)?

Also the sign of the `cos` component is wrong for a bunch of inputs. On Thursday, June 22, 2017 8:16:21 PM CEST Boris Zbarsky wrote: > On 6/22/17 2:13 PM, Алексей wrote: > > function sincos (a) { > > > > const sin = Math.sin(a) > > const cos = (1 - sin**2)**0.5 > > This will completely

Re: are there metrics on how es6 and future proposals affect javascript load-time for webpages?

I don't think that this is a well-defined question. Is "load time" equivalent to "parse time"? Is it "compile time"? Is it both? Is it something else? Are we talking about engines that don't generate native code and thus maybe "interpretation time"? What are we measuring when you say

Re: Deterministic Proposal

h for your application only to memoize the last `n` results. If you don't, depending on your function, you might be blowing up memory rather quickly. On Wednesday, June 21, 2017 1:03:20 AM CEST kdex wrote: > Can already be solved using decorators. Thus, no need for new syntax. > If we get a

Re: Deterministic Proposal

Can already be solved using decorators. Thus, no need for new syntax. If we get a standard library to import some common decorators from, one could easily write: ```js import { memoize } from "std::decorators"; @memoize function sum(a, b) { return a + b; } ``` On Wednesday, June 21,

Re: p-norms, Vector

Thanks for the pointers! > `array.reduce( (a,b)=>a+b )` (Although I wouldn't object to `Math.sum()`) Yes; no objections here. > `Math.hypot(...array)` I'm aware of `Math.hypot`, but it only covers `p = 2`. The important thing about `Math.hypot` is that it doesn't demolish numbers with high

p-norms, Vector

In mathematics, the p-norm of a vector is defined as in [1]. For p = 1, we get the taxicab norm, for p = 2 we get the Euclidean norm, and for the limit as p → ±∞ we get the maximum/minimum norm. Particularly the Euclidean norm is pretty common in graphics-related code. This could be

Re: Proposal: Boolean.parseBoolean

One could argue that `parse` makes more sense, as there is really just that one way to parse a bool. On Monday, March 20, 2017 8:04:53 PM CET Dmitry Soshnikov wrote: > On Mon, Mar 20, 2017 at 11:57 AM, T.J. Crowder < > tj.crow...@farsightsoftware.com> wrote: > > > Any reason for not just using

Re: Standardizing conditional try/catch

they can be added later. > > This proposal introduces the minimum number of features needed to handle > the dynamic nature of JS. > > Thank you, > -Zach Lym > > On Sun, Mar 19, 2017 at 8:23 AM, kdex <k...@kdex.de> wrote: > > > Well, there has been some dis

Re: Standardizing conditional try/catch

proposal - so I would > consider it to be a dead end or wishful thinking. > > On Sat, Mar 18, 2017 at 5:16 PM, kdex <k...@kdex.de> wrote: > > > I'm not sure if embedding this idea into the language will make future > > ideas about true pattern matching harde

Re: Standardizing conditional try/catch

I'm not sure if embedding this idea into the language will make future ideas about true pattern matching harder to implement or not. Destructuring assignments are pretty slow from what I've measured, and they still made it in, so I hardly see performance being a showstopper here. On Saturday,

Re: Feedback on Iterable Numbers Proposal?

On that note, it might make more sense to add range literals. On Sunday, February 26, 2017 8:39:28 PM CET kdex wrote: > I like this proposal a lot! > > The only thing I'd like to remark is that I can see people getting confused > about the exact range that you're iterating

Re: Feedback on Iterable Numbers Proposal?

On that note, it might make more sense to add range literals. On Sunday, February 26, 2017 8:39:28 PM CET kdex wrote: > I like this proposal a lot! > > The only thing I'd like to remark is that I can see people getting confused > about the exact range that you're iterating

Re: Feedback on Iterable Numbers Proposal?

I like this proposal a lot! The only thing I'd like to remark is that I can see people getting confused about the exact range that you're iterating over. Some languages provide constructs to include/exclude the last element in the range. On Sunday, February 26, 2017 8:00:39 PM CET John Henry

Re: Array Comprehensions

AFAIK, only TC39 members can champion a proposal. If you're not a member, you could still write a proposal and hope that some TC39 member is interested in championing it. On Tuesday, February 7, 2017 5:05:49 PM CET Ryan Birmingham wrote: > It wasn't clear from the documentation; who can or

Re: Or Equal Operator

Not that I know of. I think It also went down as the "mallet operator" and got supported by babel at some point. On Saturday, February 4, 2017 5:02:46 AM CET Артем Гуржий wrote: > Is there proposal for this? > ___ > es-discuss mailing list >

Re: Short Comparing proposal

I actually don't think this is worth pursuing, as it can easily be implemented by libraries once we solve operator overloading, without adding new syntax: `` if (1 < [2, 3]) `` Am 01.02.2017 um 18:12 schrieb Ryan Birmingham: I have a handfull of questions on this proposal as well: How would

Re: Ranges

l this throw? Is the empty string > > included in the iterator? > > 2016年11月3日(木) 21:18 Viktor Kronvall <viktor.kronv...@gmail.com>: > > > > Actually, after giving it some more thought for that case there is just > > that one possibility that makes se

Re: Ranges

language (which also uses functions for most > > utilities). > > > > Maybe a `Number.range` would work? > > > > ```js > > Number.range = function *range(start, end=undefined, step=1) { > > if (end === undefined) [start, end] = [0, start]; > >

Re: Ranges

Agreed. There's no reason why `Array.range` or `[1..10]` couldn't just return a generator or at least something that extends a generator, though. I wonder if it's viable to implement something akin to `.length` on ranges, which could be natural numbers or `Infinity`. As for numbers, I don't

Ranges

A few months ago, there was a thread on ESDiscuss [1] where somebody asked for native `Range` support, i.e. numeric ranges, string ranges, etc. It seems like it didn't receive much attention, so I'd like to bring this up for discussion again. If you were to iterate from X to Y, you would

Re: Conditional object properties

I'd imagine that from an engine point of view, this means that fewer object shapes land in memory, at least for v8. Reducing the number of object shapes currently boils down to using an object literal and setting the properties to `value || null` instead of extending the object with new

Re: Proposal: `await [p1, p2]` (equivalent to `await Promise.all([p1, p2])`)

what ever happened to that. On Wednesday, October 26, 2016 1:27:28 AM CEST Olivier Lalonde wrote: > Right it makes sense, should have thought about that! An `awaitAll` (or > other syntax) could be nice but it seems the general opinion is against. > > On Wed, Oct 26, 2016 at 1:22

Re: Proposal: `await [p1, p2]` (equivalent to `await Promise.all([p1, p2])`)

It's especially beneficial for designing APIs where you don't care about if users pass you a `Promise` or the actual data to work with. Imagine a scenario where you would like to remove a set of files: ```js async function remove(filesArray) { const files = await filesArray; /* …

Re: Proposal: `await [p1, p2]` (equivalent to `await Promise.all([p1, p2])`)

This change is not backwards-compatible. Note that the semantics of the following example would change: ```js (async () => { const result = await [new Promise(resolve => { setTimeout(resolve, 1000); })]; })(); ``` Now, what should `result` contain? `await` can already be used on

User-defined literals

- Numbers may be specified in arbitrary bases (e.g. `124_9 === Number.parseInt(124, 9)`) - Complex numbers, quaternions, … (you could make these even nicer with operator overloading) Any opinions? — kdex [1] http://en.cppreference.com/w/cpp/language/user_literal [2] https://mail.python.org

Re: Proposal: `if-else` and `switch` as expressions

You could also use babel's stage-0 preset to experiment with do-expressions. On 09/11/2016 06:18 PM, Caitlin Potter wrote: You might be interested in the "do-expressions" feature in v8. I'm not sure how much it's been discussed in the committee, but it's implemented (partially) in V8, so you

Re: Thought about const

I use `const` by default as well, but I don't think saving two characters is worth giving up readability. Newcomers might even think that "ungrammatical" abbreviations such as `cst` could stand for `cast`, `constructor` or similar terms related to programming. In terms of hindsight, it could

Re: Symbol for modifying property lookup?

Callable class constructors [1] have been discussed at some point. They've been withdrawn [2] in favor of decorators [3], though. [1] https://github.com/tc39/ecma262/blob/master/workingdocs/callconstructor.md [2]

Re: Is ES officially a PascalCase and camelCase langauge?

anigans I'd like to see disappearing once > we have a clear "it's either quoted 'background-color' or backgroundColor > for properties and never 'background_color'". > > How difficult could this be? > > Regards > > > > On Tue, Jun 28, 2016 at 9:58 AM,

Re: Is ES officially a PascalCase and camelCase langauge?

I'd appreciate that, too, but I think the scope should be much bigger than just ES (which is hard to enforce). Right now, we even see some deviations in certain Web APIs that are designed to interoperate with ES to some degree. See for example [1] or [2]. One of the most opposing trends (and

Re: Process of proposing targeted deconstruction

ST Caitlin Potter wrote: > Honestly, I don’t think so — Colloquially, it’s just easier to deal with > small indexes vs dates/years. They’re shorter, they don’t change as often (in > theory). It’s a hard habit to break for most people. > > > On Jun 1, 2016, at 10:09 A

Re: Process of proposing targeted deconstruction

@caitlin Good find, but this directory name was presumably only given to match the naming scheme of [1] and [2]. Somebody should probably do the work and rename them all. @leo: The Chrome Platform Status page [3] also mentions "ES8". [1]

Re: AND and OR in if statement

Could you explain how your second example is cleaner? All I see is that it's longer; the rest is merely a matter of taste. JavaScript's syntax was, amongst others, heavily influenced by C-family languages (which went for `&&` and `||` as well as `&` and `|`). Next, I think it's confusing that,

Re: String concatination without +

@Cedric: Your proposed change would break template literals. Consider this example: ```js const tag = () => 1; console.log(tag`test`); // Valid syntax, but no way to keep apart tagged template literals from your syntax syntactically ``` Further, with your approach, I don't see a way to take

Re: String concatination without +

No one says you have to use the "+" operator. Why don't you use template literals? On Dienstag, 17. Mai 2016 16:35:28 CEST Cedric neuland wrote: > Hi, > > > > I hope this is the right place for this.. > I was wondering why this: 1+'b' +"c"cant be written like this: 1'b' > "c" >

Re: operator overloading proposal

@Isiah: Comparing your syntax proposal to `Function.defineOperator`, it appears to me that overloading an operator multiple times (e. g. unary/binary plus operator) might become painful, assuming that the semantics follow the same variadic approach that regular functions do. That is, of

Re: Import wildcards on the right side of the statement

A browser couldn't possibly resolve globs at runtime without you providing some additional information to the runtime environment, so I don't see how this could be implemented. It's not really about browsers, anyway; the ES environment knows nothing about files, either. (meaning that `require`

Re: JavaScript Language feature Idea

ed > > to > > > use that Array implementation, imposing potentially critical problems > > with, > > > for example, performance and expected behavior. It's just not a good > > idea. > > > > > > I missed off esdiscuss when I replied earlier, but I

Re: JavaScript Language feature Idea

gt; > ```js > Array.prototype[Symbol.propertyAccess] = function(index) { > if (index < 0) ... > else ... > } > ``` > > ? Just an idea; I'm not sure if that's a good use for Symbols. We > could then easily add this helper code to a given app. > > On Mon, Apr 18, 2016 at 10:2

Re: JavaScript Language feature Idea

I don't see a good reason why to mangle with this. Note that you can achieve this behavior without breaking backwards compatibility with ES6 Proxies: ```js class MyArray extends Array { constructor(...args) { super(...args); function

Re: Class and Property Initialization

Already considered and to be implemented via strong mode IIRC. On 18.03.2016 14:36, Brian Barnes wrote: I know properties on classes are getting a look over for the next iteration (last I checked) and I understand javascript is obviously a different language then other oo languages with a

  1   2   >