Here's how I see this post:
- Performing Evented I/O well is one of the biggest use cases of
JavaScript - in the browser, in mobile apps, on the server and generally.
- Exceptions in I/O scenarios did not traditionally post a problem
since constructs like callbacks and promises were used.
Benjamin (Inglor) Gruenbaum wrote:
Can I take a look at the `catch (e if) {` proposal? Is it available
online? What were the objections to it?
That was 15 years ago, so lost in the ashes of Netscape, I think. Well
before es-discuss or the modern era.
Let's see what Andreas comes up with. We
If I’m reading the latest draft correctly, `RegExpUnicodeEscapeSequence`s
aren’t allowed in regular expressions without the `u` flag. Why is that?
AFAICT, the only situations that require looking at code points rather than
UCS-2/UTF-16 code units in order to support full Unicode are:
* the
I think that the first of these has been established, there was a
suggestion raised about the third and I have no idea about the fourth. I do
however, admit that the patterns proposal doesn't sound to me like it has
enough to solve this use case, or that I understand how the two are that
On Thu, Nov 21, 2013 at 2:41 PM, Mathias Bynens math...@qiwi.be wrote:
I’d suggest allowing `\u{xx}`-style escape sequences everywhere, and
simply changing the behavior of the resulting regular expression depending
on the `u` flag. There’s no good reason to disallow e.g. `/\u{20}/` or even
Thanks Brendan,
Refutable patterns not being near consensus sounds like getting this done
could be a lot of work both implementing it and figuring out a proposal
people agree on.
Maybe I'm understanding it wrong, but the related bit is:
```
GuardedPattern(refutable) ::= Pattern(refutable) if
* Allen Wirfs-Brock wrote:
On Nov 21, 2013, at 5:28 AM, Henri Sivonen wrote:
On Thu, Nov 21, 2013 at 7:53 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
Just to be clear about this. My tests directly tested JavaScript built-in
JSON parsers WRT to BOM support in three major browsers. The
On Nov 21, 2013, at 5:28 AM, Henri Sivonen wrote:
On Thu, Nov 21, 2013 at 7:53 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
Just to be clear about this. My tests directly tested JavaScript built-in
JSON parsers WRT to BOM support in three major browsers. The tests directly
invoked
On Thu, Nov 21, 2013 at 1:35 PM, Henri Sivonen hsivo...@hsivonen.fi wrote:
UTF-32 harms JSON interchange, because Gecko removed all UTF-32
support throughout the engine (other engines probably did, too, but
I'm too busy to check) and, therefore, XHR responseType = json
doesn't support UTF-32.
On 21 Nov 2013, at 09:41, Bjoern Hoehrmann derhoe...@gmx.net wrote:
Is there any chance, by the way, to change `JSON.stringify` so it does
not output strings that cannot be encoded using UTF-8? Specifically,
JSON.stringify(JSON.parse(\\uD800\))
would need to escape the surrogate instead
On Thu, Nov 21, 2013 at 12:55 PM, Brendan Eich bren...@mozilla.com wrote:
So, we need the well-championed, thought-through, pattern-matching proposal
first. It won't take too long, I bet, and in any event you are *not* going
to get browsers implementing catch-if quickly -- I am 100% sure of
* John Cowan wrote:
Bjoern Hoehrmann scripsit:
Is there any chance, by the way, to change `JSON.stringify` so it does
not output strings that cannot be encoded using UTF-8? Specifically,
JSON.stringify(JSON.parse(\\uD800\))
would need to escape the surrogate instead of emitting it
12 matches
Mail list logo
