Proposal seeking champion: Uniform parsing of quasi-standard Date.parse input

TL;DR: https://github.com/gibson042/ecma262-proposal-uniform-interchange-date-parsing A conversation bubbled up on IRC a while back about how implementations handle unusual Date.parse input, and I've been thinking about it on and off ever since. It turns out that engines are all over the place

Re: Proposal seeking champion: Uniform parsing of quasi-standard Date.parse input

See also https://github.com/tc39-transfer/proposal-date-time-string-format On Fri, Jun 29, 2018 at 1:01 PM, Richard Gibson wrote: > TL;DR: https://github.com/gibson042/ecma262-proposal-uniform- > interchange-date-parsing > > A conversation bubbled up on IRC a while back about how

Re: Proposal seeking champion: Uniform parsing of quasi-standard Date.parse input

I saw that, but the links are dead, it appears to be abandoned, and the goals don't quite align with what I'm trying to address. As I noted, specifying what must be accepted is only half of a solution (and frankly, the current state of what gets accepted is pretty good). But I believe it's also

Re: Small Proposal "!in"

```js if (!obj.x && !obj.y) { doit() } ``` The cases where they are equal to 0, '', null, undefined shouldn't matter imo, if for example those x and y are numbers, they would be defined, defaulted to 0, and you would test for `!== 0` rather if needed Le jeu. 28 juin 2018 à 18:31, Guylian Cox

Re: [Proposal] New syntax for lazy getters

FWIW, individual parts of the "grid" don't all have to ship at the same time. Private instance fields are farther along than private static fields, for instance, and private methods are being considered separately from private fields. Another example is with async functions beating async