Re: Support () => {}() syntax?

2016-09-29 Thread Olivier Lalonde
Thanks, I wasn't aware of `do` expressions. > Why introduce the function and cognitive overhead? Not that it really matters (I was just giving an example) but your alternative isn't achieving the same thing, which is to set a default to width and height if and only if *neither* height or width

Re: Proposal: add an option to omit prototype of objects created by JSON.parse()

2016-09-29 Thread Danielle McLean
From: Olivier Lalonde (mailto:olalo...@gmail.com) Date: 30 September 2016 at 07:21:10 > Given that JSON.parse doesn't necessarily return an object, would the > noPrototype option would be ignored on e.g. `JSON.parse('"some string"')` or > `JSON.parse('true')`? The noPrototype option should set

Re: Support () => {}() syntax?

2016-09-29 Thread Rick Waldron
On Thu, Sep 29, 2016 at 3:14 PM Michał Wadas wrote: > Similar proposal is already here, do expressions. > Additionally... > > On 30 Sep 2016 12:06 a.m., "Olivier Lalonde" wrote: > >> I occasionally write IIFE to avoid introducing `let` variables,

Re: Support () => {}() syntax?

2016-09-29 Thread Michał Wadas
Similar proposal is already here, do expressions. On 30 Sep 2016 12:06 a.m., "Olivier Lalonde" wrote: > I occasionally write IIFE to avoid introducing `let` variables, e.g.: > > ``` > const thumb = ({ width, height }) => { > const { w, h } = (() => { > // if either

Support () => {}() syntax?

2016-09-29 Thread Olivier Lalonde
I occasionally write IIFE to avoid introducing `let` variables, e.g.: ``` const thumb = ({ width, height }) => { const { w, h } = (() => { // if either width or height is set, don't set any default if (Number.isInteger(width) || Number.isInteger(height)) { return { w: width, h:

Re: Proposal: add an option to omit prototype of objects created by JSON.parse()

2016-09-29 Thread Olivier Lalonde
Given that JSON.parse doesn't necessarily return an object, would the noPrototype option would be ignored on e.g. `JSON.parse('"some string"')` or `JSON.parse('true')`? On Wed, Sep 28, 2016 at 9:46 AM, 段垚 wrote: > 在 2016/9/29 0:04, Michał Wadas 写道: > > Have you ever

Feature Request: Make ECMA262 a superset of JSON

2016-09-29 Thread Richard Gibson
ECMAScript claims JSON as a subset twice in https://tc39.github.io/ecma262/#sec-json.parse , but (as has been well-documented) that is not true because it JSON strings can contain unescaped U+2028 LINE SEPARATOR and U+2029 PARAGRAPH SEPARATOR while ECMAScript strings cannot. Mark Miller alludes to

Re: JSON.stringify

2016-09-29 Thread Mark S. Miller
On Thu, Sep 29, 2016 at 9:25 AM, Alexander Jones wrote: > Maybe we should just make U+2028 and U+2029 valid in JS then? What other > productions in JSON are invalid syntax in JS? IIRC, Doug Crockford, possibly Mike Samuel, and I (and perhaps others) advocated such a change to

Re: JSON.stringify

2016-09-29 Thread Mike Samuel
On Wed, Sep 28, 2016 at 10:06 AM, Michał Wadas wrote: > Idea: require implementations to stringify "" as "<\uscript>". > > Benefits: remove XSS vulnerability when injecting JSON as content of >

Re: JSON.stringify

2016-09-29 Thread Mike Samuel
On Thu, Sep 29, 2016 at 9:25 AM, Alexander Jones wrote: > Maybe we should just make U+2028 and U+2029 valid in JS then? What other > productions in JSON are invalid syntax in JS? I don't think any other productions in JSON are invalid syntax in an Expression context. JSON places

Re: JSON.stringify

2016-09-29 Thread Alexander Jones
Maybe we should just make U+2028 and U+2029 valid in JS then? What other productions in JSON are invalid syntax in JS? On Thursday, 29 September 2016, Mike Samuel wrote: > On Thu, Sep 29, 2016 at 8:45 AM, Oriol Bugzilla > > wrote:

Re: JSON.stringify

2016-09-29 Thread Mike Samuel
On Thu, Sep 29, 2016 at 8:45 AM, Oriol Bugzilla wrote: >> ECMAScript, while highly used in web browsers, should really not care >> about HTML constructs. That's where WHATWG and W3C come in. I suggest this >> type of feature should come from one of those groups, not

Re: JSON.stringify

2016-09-29 Thread Oriol Bugzilla
> ECMAScript, while highly used in web browsers, should really not care about > HTML constructs. That's where WHATWG and W3C come in. I suggest this type of > feature should come from one of those groups, not ECMA. That applies to escaping things like `` or `]]>`, and I agree. But as Mike

Re: JSON.stringify

2016-09-29 Thread Mike Samuel
On Thu, Sep 29, 2016 at 2:09 AM, Alexander Jones wrote: > In XHTML, CDATA allows a 'more' verbatim spelling of text node content. But > the end token has to be escaped, as discussed. Despite this escaping, the > text node can contain arbitrary strings. > In XHTML, you *can*

Re: JSON.stringify

2016-09-29 Thread Simon Pieters
On Wed, 28 Sep 2016 19:06:31 +0200, Michał Wadas wrote: Idea: require implementations to stringify "" as "<\uscript>". Benefits: remove XSS vulnerability when injecting JSON as content of

Re: JSON.stringify

2016-09-29 Thread Alexander Jones
In XHTML, CDATA allows a 'more' verbatim spelling of text node content. But the end token has to be escaped, as discussed. Despite this escaping, the text node can contain arbitrary strings. In XHTML, you *can* achieve the same effect without CDATA, just by escaping XML entities. Again, and