Re: Proposal: export ** from './FooBar'

On Fri, Mar 1, 2019 at 1:35 AM Cyril Auburtin wrote: > Sometimes, (particularly in React codebases) you have to write many lines > like: > ```js > export { default as FooBar } from './FooBar'; > ``` > It could be automated of course > > It could also be tuned into > ```js > export * from

Re: String identity template tag

>> JSON lists/dicts/strings, where Array/Object/String looping-methods will >> suffice. >> > >> > all other use-cases are uncommon/complicated enough that custom >> for/while loops are usually better suited than custom-iterators. >> > >> > -

Re: String identity template tag

, value) { > if (this.#iters == null) return {done: true, value: undefined} > const index = this.#index > this.#index = (index + 1) % this.#iters.length > const {done, value} = this.#iters[index][method](value) > if (done) this.#iters = undefined >

Re: String identity template tag

break; } } } while (progressed); } console.log(Array.from(ziperator([ ['a', 'b', 'c'][Symbol.iterator](), [1, 2][Symbol.iterator]() ])).join('')); // -> a1b2c (but optimized :) > On Fri, Dec 14, 2018 at 14:04 Mike Samuel wrote: > >> >> >>

Re: String identity template tag

On Fri, Dec 14, 2018 at 12:51 PM Isiah Meadows wrote: > I'll point out Kai could be on to something, although I disagree `zip` > would be the right abstraction. Maybe `Array.interleave(...arrays)`? You > could do `Array.interleave(template, args).map(String).join("")` for > similar effect, and

Object.assign interaction with __proto__ field.

Might it be a spec bug that in the below, o's prototype changes, and o.x !== b.x? const a = makeIntercepter(); const b = { x: 1 }; const o = Object.assign( {}, a, b); console.log(`o is plain Object: ${ Object.getPrototypeOf(o) === Object.prototype }`); console.log(`b.x=${ b.x }, o.x=${

Re: Submitted for your approval, JSOX

On Thu, Sep 20, 2018 at 12:48 PM J Decker wrote: > > > That could occur in a stream. (Although if it's a stream I would expect > it to come in on a websocket rather than any sort of request) But > >someText{a,b,c}[1,2,3][1,2,3] > > [1][2] > > Those are valid streams of objects...

Re: Submitted for your approval, JSOX

On Wed, Sep 19, 2018, 4:41 PM Mike Samuel wrote: > > > On Wed, Sep 19, 2018, 4:07 PM J Decker wrote: > >> (trimmed) >> >> On Wed, Sep 19, 2018 at 12:08 PM Mike Samuel >> wrote: >> >>> >>> >>> On Wed, Sep 19, 2018 at 12:01 P

Re: Submitted for your approval, JSOX

On Wed, Sep 19, 2018, 4:07 PM J Decker wrote: > (trimmed) > > On Wed, Sep 19, 2018 at 12:08 PM Mike Samuel wrote: > >> >> >> On Wed, Sep 19, 2018 at 12:01 PM J Decker wrote: >> >>> >>> I know of no exploits; all resulting strings sh

Re: Submitted for your approval, JSOX

Wed, Sep 19, 2018 at 8:14 AM Mike Samuel wrote: > >> TC39 is not really a place to spec out new transport formats. >> >> You proposed builtin support for JSON5 >> <https://esdiscuss.org/topic/json5> last year. >> JSON5 was speced and had some adoption b

Re: Submitted for your approval, JSOX

TC39 is not really a place to spec out new transport formats. You proposed builtin support for JSON5 last year. JSON5 was speced and had some adoption but that was controversial because JSON5 was not nearly as widely used as JSON. This seems to offer more

Re: Proxy target/handler access leak in Node

Nicely done! One more reason to prefer WeakMaps to properties when relating objects and secrets. On Sun, Sep 16, 2018 at 2:59 PM Darien Valentine wrote: > A few weeks ago I’d commented on an open Node github issue regarding > Proxies and inspection. While the bulk of the comment concerns an

Re: Small Proposal "!in"

On Thu, Jul 19, 2018 at 11:56 AM Michael Theriot < michael.lee.ther...@gmail.com> wrote: > For me, `hasOwn` with the different operand order isn't a problem, but >>> others may take a different view. Trying to keep the same order takes us >>> down a route like `inOwn` which I can't say I care

Re: Feature proposal

On Thu, Jul 19, 2018 at 8:54 AM Nicolas B. Pierron < nicolas.b.pier...@mozilla.com> wrote: > On Wed, Jul 18, 2018 at 6:43 PM, Mike Samuel wrote: > > Reverse is problematic on String. The index of a codepoint can't be > > subtracted from String.length since le

Re: Small Proposal "!in"

On Thu, Jul 19, 2018 at 10:40 AM Augusto Moura wrote: > Of couse the usage of `in` is most of the time is not recommended, but it > has it place. > What places does it have? I remain unconvinced that `in` has significant enough use cases to warrant high-level ergonomics were it being proposed

Re: Small Proposal "!in"

On Thu, Jul 19, 2018 at 9:26 AM Michael Theriot < michael.lee.ther...@gmail.com> wrote: > > 'string' === typeof document.createElement('input').type > > // true > > It should be noted this is a "loose check"; it does not determine whether > or not the property exists when its value equals

Re: Small Proposal "!in"

in` or `!in` on a regular basis. > On Thu, 19 Jul 2018 at 12:06 Tobias Buschor > wrote: > >> There are valid use-cases. >> As an example, some browsers have "onfocus" as an own property of >> "window", some as an inherited. >> >> ```js >> if

Re: Feature proposal

On Wed, Jul 18, 2018 at 2:06 PM Nicolas B. Pierron < nicolas.b.pier...@mozilla.com> wrote: > On Wed, Jul 18, 2018 at 5:31 PM, Michael Luder-Rosefield > wrote: > > At the moment, we have: > > > > every > > filter > > find > > findIndex > > forEach > > indexOf / lastIndexOf > > map > > reduce /

Re: Small Proposal "!in"

write code that seems to work in casual testing but has subtly wrong semantics. > On Wednesday, July 18, 2018, Mike Samuel wrote: > >> >> >> On Wed, Jul 18, 2018 at 11:05 AM Michael Theriot < >> michael.lee.ther...@gmail.com> wrote: >> >>&

Fwd: Small Proposal "!in"

[sorry dropped group] On Fri, Jul 13, 2018 at 11:36 AM wrote: > This may be a silly idea that doesn't come naturally to others, but the > first thing I thought of was "!n", where the "!" represents a flipped > "i", so the inverse of in. > You'd need yet another restricted production which

Re: Small Proposal "!in"

On Wed, Jul 18, 2018 at 11:05 AM Michael Theriot < michael.lee.ther...@gmail.com> wrote: > I think `in` and `instanceof` could both benefit from having negated > versions. > > Assuming the developer is using `in` correctly, hasOwnProperty concerns > are irrelevant. Either way they would attempt

Re: Small Proposal "!in"

On Wed, Jul 11, 2018 at 1:51 PM T.J. Crowder < tj.crow...@farsightsoftware.com> wrote: > On Wed, Jul 11, 2018 at 4:51 PM, Alex Vincent wrote: > > In Linux programming, #!/bin/bash is very commonly the first line of a > shell > > script. In Python, we have #!/bin/python, or #!/bin/perl. The #! >

Re: FW: Proposal: safeEval

time library compiled to > “WASM” or “asm.js”. And... that’s silly. > > > For the last time, why do you believe opcode filtering can? > > *From:* Mike Samuel > *Sent:* Friday, June 22, 2018 6:04 PM > *To:* doodad-js Admin > *Cc:* Isiah Meadows ; es-discuss < >

Re: FW: Proposal: safeEval

general purpose programming > languages.* > > > > So, you don’t want JS code interpretation inside “user reports formulas”, > “template engines”, “compiler tools”, ...? > This is silly. I can want these without wanting them built using substandard tools. > > Claude >

Re: FW: Proposal: safeEval

On Fri, Jun 22, 2018, 4:56 PM doodad-js Admin wrote: > Thanks, > > > > *If you blacklist.* > > > > Blacklisting or whitelisting, that’s an open discussion. > It really isn't. *Yet you're providing a library that does just that* > > > > Because that’s a “user land” library and currently the only

Re: FW: Proposal: safeEval

On Fri, Jun 22, 2018, 4:21 PM doodad-js Admin wrote: > > > *you've provided no reason to believe that opcode filtering would provide > a better balance between security and ease of writing than AST filtering* > > > > AST filtering is fragile because every change on the language can break it. >

Re: FW: Proposal: safeEval

On Wed, Jun 20, 2018 at 9:52 PM doodad-js Admin wrote: > Thanks > > > > *How can we discuss your idea separately from the library?* > > > > I’m more thinking at the runtime level than at the “user land”. To be > honest, I don’t care of “safeEval” on “user land”. > You seem to be asking for

Re: FW: Proposal: safeEval

20, 2018, 9:12 PM doodad-js Admin wrote: > I don't want to propose you my library, I want to propose you the idea. > > -Original Message- > From: impinb...@gmail.com On Behalf Of Isiah Meadows > Sent: Wednesday, June 20, 2018 7:57 PM > To: Mike Samuel > Cc: doodad-

Re: FW: Proposal: safeEval

On Wed, Jun 20, 2018 at 2:26 PM doodad-js Admin wrote: > > > I was not aware of that proposal or didn’t pay attention.I think > “safeEval” provides ACLs, while your proposal don’t. > Neither the realms proposal nor the frozen realms proposal include ACLs. Where are the ACLs in safeeval? I see

Re: Inline ES Modules

On Wed, Jun 20, 2018 at 10:44 AM Sultan wrote: > > Additionally there are aspects that bundlers have a hard time replicating > when using ES modules as an authoring format. Consider the following > example, where ES modules might maintain a "live" binding. > > ``` > // a.js > import {b} from

Re: Re: Inline ES Modules

mic import of data > URI module worked</p>`)'); > > ``` > > demo: https://necessary-hallway.glitch.me/ > > All three seem to work! Very cool. > https://github.com/w3c/webappsec-csp/issues/243 : "Any protection against dynamic module import?" captures th

Re: Proposal: safeEval

How would this compare to https://github.com/tc39/proposal-frozen-realms ? I'm not sure how to run @doodad-js/safeeval in node since require doesn't provide obvious access to safeeval, but the code seems to do AST filtering. What does it do for inputs like safeEval('

Re: Re: Inline ES Modules

possibly I’m misunderstanding this quite > a bit, hm ... I’m also confused by the relationship between import/import() > and XSS that you’ve described. > > On Tue, Jun 19, 2018 at 8:06 PM Mike Samuel wrote: > >> CSP with data URIs is possible via nonce sources. For data: mod

Re: Re: Inline ES Modules

CSP with data URIs is possible via nonce sources. For data: module descriptors browsers could safely skip the CSP check since it doesn't allow XSS unless one can already specify an import statement which typically means one can specify arbitrary JS. That argument doesn't extend to the import

Re: Re: Inline ES Modules

On Tue, Jun 19, 2018 at 3:48 PM Jamie wrote: > I think having an inline module format would help make the composition of > build tools much easier. > > Right now we have an ecosystem where everyone builds libraries into > bundles using tools like Parcel, Rollup, Browserify, and Webpack. These >

Re: Inline ES Modules

How would an inline module be imported? Module descriptors are roughly relative URLs so can refer to a JavaScript source file, but it sounds like you'd need something more fine-grained to refer to an inline module. Using fragments to refer to a passage within a document instead of a location

Re: Symbol history

https://esdiscuss.org/topic/private-slots """ Allen Wirfs-Brock (5 years ago) As further evidence, the word "private" does not even occur in sections 8.1.6 and 8.1.6.1 of the current ES6 draft. These are the sections that define the ES6 object model. Small changes and additions had to be made to

Re: Web Security Puzzles with a TC39 agenda

; unexpandable dots. Copy/paste error? > > (Needless to say, I am interested ;).) > > > On Mon, Apr 30, 2018 at 8:02 AM, Mike Samuel <mikesam...@gmail.com> wrote: > >> I put together a short video series of web security puzzles [1] to >> motivate what I'm presenting

Web Security Puzzles with a TC39 agenda

I put together a short video series of web security puzzles [1] to motivate what I'm presenting at the May meeting [2]. cheers, mike [1] https://medium.com/@mikesamuel/puzzling-towards-security-a12b9427124 [2] https://github.com/tc39/agendas/blob/master/2018/05.md Puzzling Towards

Re: Accessing (n)th key from an object

On Tue, Apr 24, 2018 at 9:54 AM, somonek wrote: > Hi all, > > Assuming that > > const myObject = { > one: 123, > two: 456, > }; > > could > myObject[in 0] === 'one' // true > > be a better alternative of > Object.keys(myObject)[0] > > and > myObject[in 3] === undefined > >

Re: Share a secret across ES6 specific modules, so that other modules cannot access the secret?

The box function defined in github.com/mikesamuel/tc39-module-keys enables things like this. On Sun, Apr 23, 2017 at 4:42 PM, /#!/JoePea wrote: > Is there a way to share some secret value across a few modules, and > prevent other modules? f.e. prevent modules of an app dev who

Re: EcmaScript Proposal - Promised functions

This seems like it could be done with decorators per https://github.com/tc39/proposal-decorators without introducing a new keyword. @promises function sleep(...) { ... } On Thu, Apr 12, 2018 at 12:07 PM, Luiz Felipe Frazão Gonçalves < luizfelipefrazaogoncal...@gmail.com> wrote: > *One new

Re: partial spread syntax

On Sun, Mar 25, 2018 at 9:20 PM, 月の影 <19511...@qq.com> wrote: > Sometimes I got a infinity iterable sequences, I may want a partial spreed > syntax. `...iterableObject{from, to}` > How would you prevent ambiguity between the spread and blocks? iterable { from, to }; is currently equivalent

Re: Proposal: if variable initialization

t; } > > > > `while` would be a bit unnecessary, due to the fact that it can be > > replicated with `for( ; ; )`, but could be > > available for consistency with `if` and `switch`. > > > > El mié., 21 mar. 2018 19:47, Mike Samuel <mikesam...@gmail.com> &

Re: Proposal: if variable initialization

TIL On Wed, Mar 21, 2018 at 2:29 PM, kai zhu wrote: > /*jslint > stupid: true > */ > ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: if variable initialization

On Wed, Mar 21, 2018 at 1:27 PM, Sebastian Malton wrote: > Because block-level scoping is a very good way to avoid certain bugs and > is easier to reason about. Especially when considering project successors. > +1. function-scoped variables in loop bodies caused tons of

Re: Proposal: if variable initialization

On Wed, Mar 21, 2018 at 11:02 AM, Rodrigo wrote: > My proposal is to keep it simple and implement the if-assignment `if( > const o = ...; ! o ) { ... }` mimicking the `for(;;)` assignment > behavior. > Fair enough. If the assignment is separate from the condition, then

Re: Proposal: if variable initialization

On Tue, Mar 20, 2018 at 3:57 PM, Rodrigo wrote: > Proposal: inline let/const statements to declare and initialize > variables within if statements, so that temporary variables exist only > within the if/else block scope. > With setters you can get some oddities because

Re: Pointers

There is a spec reference type. It was initially there for host objects, and IIRC, most were happy to see it go. http://www.ecma-international.org/publications/files/ECMA-ST-ARCH/ECMA-262,%203rd%20edition,%20December%201999.pdf 8.7 The Reference Type The internal Reference type is not a

Re: JSON.canonicalize()

On Mon, Mar 19, 2018 at 10:30 AM, Anders Rundgren < anders.rundgren@gmail.com> wrote: > On 2018-03-19 15:17, Mike Samuel wrote: > >> >> >> On Mon, Mar 19, 2018 at 9:53 AM, Anders Rundgren < >> anders.rundgren@gmail.com <mailto:anders.rundgren@

Re: Arbitrary precision numbers in JSON

On Mon, Mar 19, 2018 at 10:09 AM, Anders Rundgren < anders.rundgren@gmail.com> wrote: > On 2018-03-19 14:43, Mike Samuel wrote: > >> Maybe have a parser function that receive the text of the number? If no >> callout is specified, it could throw an appropriate error. &

Re: JSON.canonicalize()

On Mon, Mar 19, 2018 at 9:53 AM, Anders Rundgren < anders.rundgren@gmail.com> wrote: > On 2018-03-19 14:34, Mike Samuel wrote: > >> How does the transform you propose differ from? >> >> JSON.canonicalize = (x) => JSON.stringify( >> x, >>

Re: Arbitrary precision numbers in JSON

Maybe have a parser function that receive the text of the number? If no callout is specified, it could throw an appropriate error. JSON.safeParse(json, optionalReviver, optionalParseUnrepresentable) That would allow it to tie into future proposals like decimal, and in conjunction with a

Re: JSON.canonicalize()

How does the transform you propose differ from? JSON.canonicalize = (x) => JSON.stringify( x, (_, x) => { if (x && typeof x === 'object' && !Array.isArray(x)) { const sorted = {} for (let key of Object.getOwnPropertyNames(x).sort()) { sorted[key] = x[key]

Re: JSON.canonicalize()

On Sun, Mar 18, 2018, 4:50 PM Anders Rundgren <anders.rundgren@gmail.com> wrote: > On 2018-03-18 20:15, Mike Samuel wrote: > > I and others have been trying to move towards consensus on what a > hashable form of > > JSON should look like. > > > >

Re: Summary of Input. Re: JSON.canonicalize()

On Sun, Mar 18, 2018, 4:00 PM Anders Rundgren <anders.rundgren@gmail.com> wrote: > On 2018-03-18 20:23, Mike Samuel wrote: > > It is possible that I don't understand what you are asking for here > since I have no experience with toJSON. > > > > Based on

Re: Summary of Input. Re: JSON.canonicalize()

On Sun, Mar 18, 2018 at 12:50 PM, Anders Rundgren < anders.rundgren@gmail.com> wrote: > On 2018-03-18 15:13, Mike Samuel wrote: > >> >> >> On Sun, Mar 18, 2018 at 2:14 AM, Anders Rundgren < >> anders.rundgren@gmail.com <mailto:anders.rundgren..

Re: JSON.canonicalize()

On Sun, Mar 18, 2018 at 2:18 PM, Anders Rundgren < anders.rundgren@gmail.com> wrote: > On 2018-03-18 19:04, Mike Samuel wrote: > >> I think you misunderstood the criticism. JSON does not have numeric >> precision limits. >> > > I think I understood that,

Re: JSON.canonicalize()

; > On Sun, Mar 18, 2018, 12:15 PM Anders Rundgren < > anders.rundgren@gmail.com <mailto:anders.rundgren@gmail.com>> > wrote: > > > > On 2018-03-18 16:47, Mike Samuel wrote: > > > Interop with systems that use 64b ints is not a .001% issue. &g

Re: JSON.canonicalize()

A definition of canonical that is not tied to JavaScript's current range of values would fit into more standards than the proposal as it stands. On Sun, Mar 18, 2018, 12:15 PM Anders Rundgren < anders.rundgren@gmail.com> wrote: > On 2018-03-18 16:47, Mike Samuel wrote: &g

Re: JSON.canonicalize()

Interop with systems that use 64b ints is not a .001% issue. On Sun, Mar 18, 2018, 11:40 AM Anders Rundgren < anders.rundgren@gmail.com> wrote: > On 2018-03-18 15:47, Michał Wadas wrote: > > JSON supports arbitrary precision numbers that can't be properly > > represented as 64 bit floats.

Re: JSON.canonicalize()

On Sun, Mar 18, 2018 at 10:47 AM, Michał Wadas wrote: > JSON supports arbitrary precision numbers that can't be properly > represented as 64 bit floats. This includes numbers like eg. 1e or > 1/1e. > I posted this on the summary thread but not here.

Re: JSON.canonicalize()

On Sun, Mar 18, 2018 at 10:43 AM, C. Scott Ananian wrote: > On Sun, Mar 18, 2018, 10:30 AM Anders Rundgren < > anders.rundgren@gmail.com> wrote: > >> Violently agree but do not understand (I guess I'm just dumb...) why (for >> example) sorting on UCS2/UTF-16 Code Units

Re: JSON.canonicalize()

On Sun, Mar 18, 2018 at 10:08 AM, Richard Gibson wrote: > On Sunday, March 18, 2018, Anders Rundgren > wrote: > >> On 2018-03-16 20:24, Richard Gibson wrote: >> >> Though ECMAScript JSON.stringify may suffice for certain >>

Re: Summary of Input. Re: JSON.canonicalize()

On Sun, Mar 18, 2018 at 2:14 AM, Anders Rundgren < anders.rundgren@gmail.com> wrote: > Hi Guys, > > Pardon me if you think I was hyperbolic, > The discussion got derailed by the bogus claims about hash functions' > vulnerability. > I didn't say I "think" you were being hyperbolic. I asked

Re: add reverse() method to strings

Previous discussion: https://esdiscuss.org/topic/wiki-updates-for-string-number-and-math-libraries#content-1 """ String.prototype.reverse(), as proposed, corrupts supplementary characters. Clause 6 of Ecma-262 redefines the word "character" as "a 16-bit unsigned value used to represent a single

Re: Summary of Input. Re: JSON.canonicalize()

On Fri, Mar 16, 2018 at 9:42 PM, Anders Rundgren < anders.rundgren@gmail.com> wrote: > > > On my part I added canonicalization to my ES6.JSON compliant Java-based > JSON tools. A single line did 99% of the job: > https://github.com/cyberphone/openkeystore/blob/jose-compati >

Re: Summary of Input. Re: JSON.canonicalize()

On Fri, Mar 16, 2018 at 9:42 PM, Anders Rundgren < anders.rundgren@gmail.com> wrote: > Scott A: > https://en.wikipedia.org/wiki/Security_level > "For example, SHA-256 offers 128-bit collision resistance" > That is, the claims that there are cryptographic issues w.r.t. to Unicode >

Re: JSON.canonicalize()

On Fri, Mar 16, 2018, 4:58 PM Anders Rundgren <anders.rundgren@gmail.com> wrote: > On 2018-03-16 21:41, Mike Samuel wrote: > > > > > > On Fri, Mar 16, 2018 at 4:34 PM, C. Scott Ananian <ecmascr...@cscott.net > <mailto:ecmascr...@cscott.net>> wrote: &

Re: JSON.canonicalize()

On Fri, Mar 16, 2018 at 4:34 PM, C. Scott Ananian wrote: > On Fri, Mar 16, 2018 at 4:07 PM, Anders Rundgren < > anders.rundgren@gmail.com> wrote: > >> Perfection is often the enemy of good. >> > > So, to be clear: you don't plan on actually incorporating any feedback >

Re: JSON.canonicalize()

On Fri, Mar 16, 2018 at 3:23 PM, Anders Rundgren < anders.rundgren@gmail.com> wrote: > On 2018-03-16 20:09, Mike Samuel wrote: > >> >> Availability beats perfection anytime. This is the VHS (if anybody >> remember that old story) of canonicalization

Re: JSON.canonicalize()

On Fri, Mar 16, 2018 at 3:03 PM, Anders Rundgren < anders.rundgren@gmail.com> wrote: > On 2018-03-16 19:51, Mike Samuel wrote: > >> >> >> On Fri, Mar 16, 2018 at 2:43 PM, Anders Rundgren < >> anders.rundgren@gmail.com <mailto:anders.rundgren@

Re: JSON.canonicalize()

On Fri, Mar 16, 2018 at 2:43 PM, Anders Rundgren < anders.rundgren@gmail.com> wrote: > On 2018-03-16 19:30, Mike Samuel wrote: > >> 2. Any numbers with minimal changes: dropping + signs, normalizing zeros, >> using a fixed threshold for scientific notation. >

Re: JSON.canonicalize()

ime to process is noticably different for 1e10 vs 1e1 then the attacker can tell, via traffic analysis alone, when Alice communicates with Bob. We should avoid that in-memory blowup if possible. > --scott > > On Fri, Mar 16, 2018 at 1:46 PM, Mike Samuel <mikesam...@gmail.co

Re: JSON.canonicalize()

On Fri, Mar 16, 2018 at 1:30 PM, Anders Rundgren < anders.rundgren@gmail.com> wrote: > On 2018-03-16 18:04, Mike Samuel wrote: > > It is entirely unsuitable to embedding in HTML or XML though. >> IIUC, with an implementation based on this >> >>

Re: JSON.canonicalize()

On Fri, Mar 16, 2018 at 12:44 PM, C. Scott Ananian <ecmascr...@cscott.net> wrote: > On Fri, Mar 16, 2018 at 12:23 PM, Mike Samuel <mikesam...@gmail.com> > wrote: >> >> >> On Fri, Mar 16, 2018 at 11:38 AM, C. Scott Ananian <ecmascr...@cscott.net >>

Re: JSON.canonicalize()

On Fri, Mar 16, 2018 at 11:38 AM, C. Scott Ananian wrote: > Canonical JSON is often used to imply a security property: two JSON blobs > with identical contents are expected to have identical canonical JSON forms > (and thus identical hashed values). > What does "identical

Re: Strawman: Module Keys

On Fri, Mar 2, 2018 at 8:29 PM, Alex Vincent <ajvinc...@gmail.com> wrote: > On Wed, Feb 28, 2018 at 4:00 AM, <es-discuss-requ...@mozilla.org> wrote: > >> From: Mike Samuel <mikesam...@gmail.com>I'm looking for other criticism >> of https://github.com/mikesamuel

Strawman: Module Keys

I'm looking for other criticism of https://github.com/mikesamuel/tc39-module-keys and for interested parties who might have time to refine it. This adds public/private key analogues to ModuleBodies along with some associated operators. As background, we on Google's security engineering group

Re: Proposal to add symbol: "hasInstanceStrict"

On Tue, Feb 20, 2018 at 1:32 PM, Mike Samuel <mikesam...@gmail.com> wrote: > > > On Tue, Feb 20, 2018 at 1:20 PM, T.J. Crowder < > tj.crow...@farsightsoftware.com> wrote: > >> On Tue, Feb 20, 2018 at 6:05 PM, Mike Samuel <mikesam...@gmail.com> >> wro

Re: Proposal to add symbol: "hasInstanceStrict"

On Tue, Feb 20, 2018 at 1:20 PM, T.J. Crowder < tj.crow...@farsightsoftware.com> wrote: > On Tue, Feb 20, 2018 at 6:05 PM, Mike Samuel <mikesam...@gmail.com> wrote: > > > > I'm probably just going to echo themes that T.J. has dealt with better, > but: > > Qu

Re: Proposal to add symbol: "hasInstanceStrict"

On Tue, Feb 20, 2018 at 12:33 PM, Александр Ефремов wrote: > Anyone else has interes to this proposal? > I'm probably just going to echo themes that T.J. has dealt with better, but: Things i like: - provides preconditions - guards locals Things I don't like: - doesn't deal

Re: Proposal to add symbol: "hasInstanceStrict"

On Tue, Feb 20, 2018 at 8:37 AM, T.J. Crowder < tj.crow...@farsightsoftware.com> wrote: > On Tue, Feb 20, 2018 at 1:15 PM, Terence M. Bandoian > wrote: > > > > Wasn't JavaScript originally designed for use in the Netscape > > browser? Maybe it's more correct to say that it

Re: For-has-in loop

On Mon, Feb 19, 2018 at 1:50 PM, Sebastian Malton wrote: > I would like to propose that the following be valid since it is a very > common use case. > > ``` > for (const field has in object) { > > } > ``` > > Would be equivalent to: > > ``` > for (const field in

Re: Partial regexp matching

On Mon, Feb 19, 2018 at 1:15 PM, Isiah Meadows wrote: > > > > > We can't base a distinction between yes and maybe on whether a > > zero-width $ assertion is triggered if there are paths to completion > > that do not pass through that assertion. > > > > > > const re =

Re: Partial regexp matching

On Mon, Feb 19, 2018 at 11:43 AM, Isiah Meadows wrote: > Yes, and I specifically want the conservative variant - I'd want a > "maybe" for "foo" in that example. > > (For context, my test framework determines *while running a test* > whether that test has children, and

Re: Proposal to add symbol: "hasInstanceStrict"

On Mon, Feb 19, 2018 at 11:50 AM, Aleksander Efremov wrote: > In my first example you can found what I mean. There not only function. > Just instead of that function can be black box results which we must check > on assignment to const. > Are you referring to the use of

Re: Proposal to add symbol: "hasInstanceStrict"

On Mon, Feb 19, 2018 at 9:25 AM, T.J. Crowder < tj.crow...@farsightsoftware.com> wrote: > On Mon, Feb 19, 2018 at 1:59 PM, Александр Ефремов > wrote: > > When [decorators][1] land, provided they land with a means of [decorating > functions][2] (either as part of that proposal

Re: Partial regexp matching

So you want an API that can indicate "might match if there were more input"? Is it ok if it is conservative? I.e. it won't incorrectly say "definitely wouldn't match given more input" but could tolerate errors the other way? For example, /^food(?!)/ would have to say no for "foop" but we might

Re: Proposal to add symbol: "hasInstanceStrict"

Must hasInstanceStrict's parameter remain untyped for a guard to complete or is there a top type with an unguarded hasInstanceStrict that these checks bottom out on? "has" to my ear sounds like it should return a boolean. Maybe "require." On Feb 18, 2018 11:30 AM, "Aleksander Efremov"

Re: Suggestion: Infix operators/functions

On Fri, Feb 2, 2018 at 10:58 AM, Mike Samuel <mikesam...@gmail.com> wrote: > How would this affect ASI? > > a // no semicolon inserted since '+' is an infix operator > +b > > a // semicolon inserted since '!' is not an infix operator > !b > >

Re: Suggestion: Infix operators/functions

How would this affect ASI? a // no semicolon inserted since '+' is an infix operator +b a // semicolon inserted since '!' is not an infix operator !b but what about function '!'(a, b) { ... } // now '!' is both an infix and a prefix operator a // is a semicolon

Re: Proposal: Map#assign

On Thu, Jan 18, 2018 at 12:37 PM, T.J. Crowder < tj.crow...@farsightsoftware.com> wrote: > On Thu, Jan 18, 2018 at 5:28 PM, 森建 wrote: > > > > This code is redundant. I just want to write > > `mapA.assign(mapB, mapC);`. > > FWIW, it would be more in keeping with

Re: The Bookmarks of PDF Version ECMAScript Standard Are Broken

, Timothy Liu <tim...@outlook.com> wrote: > Thanks! Mike: > > I know the HTML version works perfectly well :) > Usually, I do my writing work in a low network speed environment, say > Starbucks. > > Best Regards, > Tim > > > -Original Message- > From

Re: Partial Expression proposal

ould we find out whether the feature is desirable? Just find a lot of use cases? Or write a *Purpose* paragraph? 2017-12-28 20:29 GMT+01:00 Mike Samuel <mikesam...@gmail.com>: > On Thu, Dec 28, 2017 at 12:10 PM, Tamás Halasi <trusted.tom...@gmail.com> > wrote: > &g

Re: Partial Expression proposal

On Thu, Dec 28, 2017 at 12:10 PM, Tamás Halasi wrote: > Damn. > I wonder why is that useful. > But whatever. > > What symbol do you think would be the best? > A binary operator have to have an expression at its left side, so *, /, %, >>, <, &, ^ or | might be good. If

Re: Partial Expression proposal

On Wed, Dec 27, 2017 at 1:43 PM, Tamás Halasi wrote: > It's like the functional application proposal, just for any expression. It > would improve This sentence ends abruptly. What would this proposal improve? > See the proposal: >

Re: The JavaScript character wall

On Thu, Dec 14, 2017 at 5:39 AM, Gareth Heyes wrote: > Hi all > > So many years ago on the sla.ckers forums Yosuke Hasegawa posted > non-alphanumeric JavaScript. We then worked together to find out the > smallest possible charset required to execute non-alphanumeric

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

On Thu, Dec 7, 2017 at 1:11 PM, Alex Vincent wrote: > OK, OK, clearly, pure functions are a fantasy in JavaScript. Once again, a > great idea and a lengthy essay of a post falls to a real-world situation. > Nuts. > > What if there's a middle ground? In the case I was

Re: Syntax is the Problem

On Sun, Nov 5, 2017 at 8:22 AM, Michael Lewis wrote: > Raul-Sebastian Mihăilă just made a post here about some mixin syntax. I > didn't read it (sorry). > > But, it got me thinking about a concept I've been thinking for years: *syntax > is the problem*, and there's a better

  1   2   3   4   >