In most environments, Error#message is enumerable, e.g.
try {
LOLWAT; // throws a ReferenceError
} catch(e) {
for (var i in e) {
console.log(i);
}
}
This enumerates the properties on the Error object and logs them one
by one to the console.
This behavior
http://wiki.ecmascript.org/doku.php?id=strawman:support_full_unicode_in_strings#unicode_escape_sequences
states:
To address this issue, a new form ofUnicodeEscapeSequence is added that is
explicitly tagged as containing var variable number (up to 8) of hex digits.
The new definition is:
Norbert echoes my thoughts perfectly:
Using a Unicode escape for non-textual data seems like abuse to me -
Unicode is a character encoding standard. For Unicode, anything beyond six
hex digits is excessive.
Allen, what use cases for using Unicode escapes / strings for non-textual
data did you
On a side note, if we're going to do this, can we also have aliasses
in regex to parse certain unicode categories? For instance, the es
spec defines the Uppercase Letter (Lu), Lowercase Letter (Ll),
Titlecase letter (Lt), Modifier letter (Lm), Other letter (Lo),
Letter number (Nl),
Oh my, that was embarrassing. Haven’t trolled myself like that in a long time.
Thanks Yusuke!
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
For example, U+2F800 CJK COMPATIBILITY IDEOGRAPH-2F800 is a supplementary
Unicode character in the [Lo] category, which leads me to believe it should
be allowed in identifier names. After all, the spec says:
UnicodeLetter = any character in the Unicode categories “Uppercase letter
(Lu)”,
Why should e.g. '\u2xao' throw an error? I can’t find this in the spec, but
Test262 actually has a test for this behavior so I must be missing
something obvious.
I know `UnicodeEscapeSequence` is defined as follows:
UnicodeEscapeSequence :: u HexDigit HexDigit HexDigit HexDigit
But since
Code point escape:
\u{20BB7} === \uD842\uDFB7
V8 doesn't currently throw a syntax error for \u{, but that will get fixed.
Exclude 0xD800-0xDFFF? No.
What will be the maximum number of hex digits allowed in `\u{ABCDE}`?
The strawman[1] mentioned up to 8 hex digits, but it seems like 6 hex
On Thu, Apr 12, 2012 at 3:51 PM, Lasse Reichstein wrote:
/* MY CODE */
tru\u0065();
That would only work if the `true` function was defined with at least
one Unicode escape in the name (not necessarily the same one). See
For those interested, Spidermonkey doesn’t handle the following correctly:
function \u0074rue() { alert('PASS'); }
\u0074rue();
function \u0074rue() { alert('PASS'); }
tru\u0065();
Both these examples should alert 'PASS' in web browsers.
I filed this as bug 744784:
http://ecma-international.org/ecma-262/5.1/#sec-10.6 says:
When control enters an execution context for function code, an arguments
object is created unless (as specified in 10.5) the identifier arguments
occurs as an Identifier in the function’s FormalParameterList or occurs as
the
, but then overwritten by the variable declaration in step 8.
So shouldn’t the first two examples in my mail (quoted below) get the
same result, then? Or are `var arguments;` and `var arguments =
undefined;` not both `VariableDeclaration`s?
On Wed, Jul 4, 2012 at 4:03 PM, Mathias Bynens math...@qiwi.be
In the execution phase, their behavior is different.
section 12.2
http://ecma-international.org/ecma-262/5.1/#sec-12.2
var arguments = undefined
performs PutValue with reference and undefined.
1. Let lhs be the result of evaluating Identifier as described in 11.1.2.
2. Let rhs be
I’m not sure if this is the right list to ask, but would it be
possible to publish drafts
(http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts)
in HTML format as well? Would be nice to get a nice, bookmarkable HTML
resource for each draft version.
Seems like this would be
On Tue, Jul 17, 2012 at 10:23 PM, Norbert Lindenberg
ecmascr...@norbertlindenberg.com wrote:
To further clarify position. I don't currently agree with Norbert's
assertion WRT situations. For more discussion see
https://bugs.ecmascript.org/show_bug.cgi?id=469
On 3 Aug 2012, at 20:34, David Bruant bruan...@gmail.com wrote:
Le 03/08/2012 12:58, Allen Wirfs-Brock a écrit :
substr is in Annex B, which in ES5.1 is an informative annex. In ES6, the
content of Annex B will be optional normative. Required for web user
agents, but optional for other
ECMAScript 6 introduces some useful new features that make working with astral
Unicode symbols easier.
One thing that is still missing though (AFAIK) is an easy way to count the
number of symbols / code points in a given string. As you know, we can’t rely
on `String.prototype.length` here, as
Thanks for the useful info, Andrea and Yusuke!
A `{code}points` property/getter on the `String.prototype` like Andrea
suggested earlier sure sounds good to me.
IMHO a solution to the “string length” problem should definitely be added to
ES6, as even major sites like Twitter.com are doing it
On 30 Nov 2012, at 22:50, Norbert Lindenberg ecmascr...@norbertlindenberg.com
wrote:
There's nothing in the proposal yet because I intentionally kept it small.
It's always possible to add functionality, but we need some evidence that it
will be widely used.
My guess would be that in 99% of
On 6 Jun 2013, at 15:02, gaz Heyes gazhe...@gmail.com wrote:
Meh politics. I have no interest in such matters. Breaking broken programs
shouldn't be a concern.
Welcome to the Web :)
___
es-discuss mailing list
es-discuss@mozilla.org
On 7 Jun 2013, at 18:43, David Bruant bruan...@gmail.com wrote:
Le 07/06/2013 07:31, Jason Orendorff a écrit :
Is there a canonical explanation of Don't Break the Web out there? It would
be nice to have something to point each new person to when they express this
frustration.
I usually
On 8 Jun 2013, at 19:01, Yusuke SUZUKI utatane@gmail.com wrote:
Hello all,
Seeing ECMA262 section 7.8.4,
EscapeSequence ::
CharacterEscapeSequence
0 [lookahead ∉ DecimalDigit]
HexEscapeSequence
UnicodeEscapeSequence
Because of [lookahead ∉ DecimalDigit], strictly
Great proposal, Norbert!
Another tool that uses JavaScript to identify identifiers as per ECMAScript 5.1
/ Unicode 6.2 is http://mothereff.in/js-variables.
For a list of bug reports regarding identifier handling in browsers /
JavaScript engines, see
Also, what about the non-reserved words that act like reserved words, i.e. the
immutable `NaN`, `Infinity`, and `undefined` properties of the global object,
or `eval` and `arguments` which are disallowed as identifiers (see section
12.2.1) in strict mode? IMHO, these are examples of why it
Bumping this old thread since V8 issue #90
(https://code.google.com/p/v8/issues/detail?id=90) has been getting lots of
comments lately.
It appears that unstable sort, while perfectly spec-compliant, doesn’t match
user expectations. It doesn’t help that some browsers/engines _do_ use a stable
I wrote a (new) script that generates a regular expression that matches valid
JavaScript identifiers as per ECMAScript 5.1 / Unicode v6.2.0.
http://mathiasbynens.be/demo/javascript-identifier-regex
Then, I made it do the same thing according to the latest ECMAScript 6 draft,
which refers to
On 27 Feb 2012, at 22:58, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Feb 26, 2012, at 1:55 AM, Mathias Bynens wrote:
For example, U+2F800 CJK COMPATIBILITY IDEOGRAPH-2F800 is a supplementary
Unicode character in the [Lo] category, which leads me to believe it should
be allowed
On 24 Aug 2013, at 11:02, Mathias Bynens math...@qiwi.be wrote:
Wouldn’t this be confusing, though?
global['\u{2F800}'] = 42; // would work (compatible with ES5 behavior)
global['\uD87E\uDC00'] = 42; // would work, too, since `'\uD87E\uDC00' ==
'\u{2F800}'` (compatible with ES5
On 24 Aug 2013, at 22:13, Norbert Lindenberg
ecmascr...@lindenbergsoftware.com wrote:
On Aug 24, 2013, at 2:02 , Mathias Bynens math...@qiwi.be wrote:
On 27 Feb 2012, at 22:58, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
var \ud87e\udc00 would probably still be illegal because each
I had no intentions specific to U+2E2F when I proposed relying on UTR 31 -
the change is simply the effect of the character properties that the Unicode
Technical Committee assigned to this character.
I don't think there's a real problem. U+2E2F was added in Unicode version
5.1.
On 25 Aug 2013, at 04:17, Norbert Lindenberg
ecmascr...@lindenbergsoftware.com wrote:
I don't think that's a technical problem. String.isIdentifier{Start,Part}, as
I proposed them, don't deal with actual identifiers in source text; they
check individual identifier characters.
The
On 4 Sep 2013, at 18:34, Brendan Eich bren...@mozilla.com wrote:
Here, from the latest ES6 draft, is 15.5.2.3 String.fromCodePoint (
...codePoints):
The String.fromCodePoint function may be called with a variable number of
arguments which form the
rest parameter codePoints. The
On 26 Aug 2013, at 04:08, Norbert Lindenberg
ecmascr...@lindenbergsoftware.com wrote:
On Aug 24, 2013, at 23:43 , Mathias Bynens math...@qiwi.be wrote:
I would suggest adding something like `String.isIdentifier` which accepts a
multi-symbol string or an array of code points
FWIW, here’s a real-world example of a case where this behavior is
annoying/unexpected to developers: http://cirw.in/blog/node-unicode
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On 10 Sep 2013, at 18:30, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Sep 10, 2013, at 12:14 AM, Mathias Bynens wrote:
FWIW, here’s a real-world example of a case where this behavior is
annoying/unexpected to developers: http://cirw.in/blog/node-unicode
This suggests to me
On 18 Sep 2013, at 21:05, Anne van Kesteren ann...@annevk.nl wrote:
On Mon, Aug 19, 2013 at 5:25 AM, Mathias Bynens math...@qiwi.be wrote:
After comparing the output, I noticed that both regular expressions are
identical except for the following: ECMAScript 5 allows U+2E2F VERTICAL
TILDE
Patches implementing `String.prototype.codePointAt` and `String.fromCodePoint`
are available for both SpiderMonkey
(https://bugzilla.mozilla.org/show_bug.cgi?id=918879) and V8
(https://code.google.com/p/v8/issues/detail?id=2840).
One spec bug remains to be fixed, though:
I think I'm convinced that String.fromCodePoint()'s design is correct,
especially since the rendering subsystem deals with code points too.
Glad to hear.
String.prototype.codePointAt() however still feels wrong since you
always need to iterate from the start to get the correct code *unit*
This is about the identifier identification strawman:
http://wiki.ecmascript.org/doku.php?id=strawman:identifier_identification
For tooling, it’s better to have a false positive than to have a false
negative. In the case of identifier identification, it’s more useful to flag an
identifier that
On 8 Oct 2013, at 19:59, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
The Ecma General Assembly has approved by letter ballot Ecma-404: THE JSON
Data Interchange Formal
See http://www.ecma-international.org/publications/standards/Ecma-404.htm
As for Unicode, it explicitly refers to Unicode
On 8 Oct 2013, at 22:19, Rick Waldron waldron.r...@gmail.com wrote:
On Tue, Oct 8, 2013 at 4:10 PM, Mathias Bynens math...@qiwi.be wrote:
As for Unicode, it explicitly refers to Unicode 6.2.0, even though version
6.3.0 was released last week.
The document was written in July, which
On 8 Oct 2013, at 23:39, Mark S. Miller erig...@google.com wrote:
JSON must not change. If it refers to the latest Unicode, whatever that is,
then it is potentially subject to disruption by (admittedly unlikely) future
changes to Unicode.
By that logic, it should have referred to either
CC’ing the creators of the tools we’ve been talking about to get their input.
Hi guys! Please start reading here:
http://esdiscuss.org/topic/making-the-identifier-identification-strawman-less-restrictive.
On 9 Oct 2013, at 07:48, Norbert Lindenberg ecmascr...@lindenbergsoftware.com
wrote:
-
Forwarding Anton’s message since he’s not subscribed to es-discuss.
Begin forwarded message:
From: Anton Kovalyov an...@kovalyov.net
Subject: Re: Making the identifier identification strawman less restrictive
Date: 9 October 2013 22:17:50 CEST
To: Mathias Bynens math...@qiwi.be
Cc: Norbert
...@lindenbergsoftware.com
Cc: Mathias Bynens math...@qiwi.be, es-discuss es-discuss@mozilla.org,
Anton Kovalyov an...@kovalyov.net, Yusuke SUZUKI utatane@gmail.com,
ariya.hida...@gmail.com, Jeremy Ashkenas jashke...@gmail.com,
mi...@bazon.net
I have no particular opinion about this. Identifiers
On 2 Oct 2013, at 10:45, Petka Antonov petka_anto...@hotmail.com wrote:
In current version, this works just fine:
var let = 6;
Note that `let` was reserved in strict mode (only) in ES5, meaning that even as
per ES5 that snippet only works in sloppy mode.
ES6 fixes `String.fromCharCode` by introducing `String.fromCodePoint`.
Similarly, `String.prototype.charCodeAt` is fixed by
`String.prototype.codePointAt`.
Should there be a method that is like `String.prototype.charAt` except it deals
with astral Unicode symbols wherever possible?
On 18 Oct 2013, at 09:21, Rick Waldron waldron.r...@gmail.com wrote:
I think the idea is good, but the name may be confusing with regard to
Symbols (maybe not?)
Yeah, I thought about that, but couldn’t figure out a better name. “Glyph” or
“Grapheme” wouldn’t be accurate. Any suggestions?
Here’s my proposal. Feedback welcome, as well as suggestions for a better name
(if any).
## String.prototype.symbolAt(pos)
NOTE: Returns a single-element String containing the code point at element
position `pos` in the String `value` resulting from converting the `this`
object to a String.
On 18 Oct 2013, at 10:48, Anne van Kesteren ann...@annevk.nl wrote:
On Fri, Oct 18, 2013 at 1:46 PM, Mathias Bynens math...@qiwi.be wrote:
Similarly, `String.prototype.charCodeAt` is fixed by
`String.prototype.codePointAt`.
When you phrase it like that, I see another problem
On 18 Oct 2013, at 11:05, Anne van Kesteren ann...@annevk.nl wrote:
On Fri, Oct 18, 2013 at 4:58 PM, Mathias Bynens math...@qiwi.be wrote:
I disagree. In those situations you should just iterate over the string
using `for…of`.
That seems to iterate over code units as far as I can tell
Please ignore my previous email; it has been answered already. (It was a draft
I wrote up this morning before I lost my internet connection.)
On 18 Oct 2013, at 11:57, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
Given that we have charAt, charCodeAt and codePointAt, I think the most
On 18 Oct 2013, at 15:12, Andrea Giammarchi andrea.giammar...@gmail.com wrote:
so my counter-question would be: is there any way to do that in core so that
we can “”.split() it so that we can have an ArrayLike that with [1] gives
back the single “” and not the whole thing ?
This brings
On 18 Oct 2013, at 17:51, Joshua Bell jsb...@google.com wrote:
Given that you can only use the proposed String.prototype.at() properly for
indexes 0 if you know the index of a non-BMP character or lead surrogate by
some other means, or if you will test the return value for a trailing
On 19 Oct 2013, at 12:15, Bjoern Hoehrmann derhoe...@gmx.net wrote:
Certainly not common enough to warrant a two-character method on the
native string type. Odds are people will use it incorrectly in an
attempt to make their code look concise […]
Are you saying that changing the name to
On 19 Oct 2013, at 00:53, Domenic Denicola dome...@domenicdenicola.com wrote:
On 19 Oct 2013, at 01:12, Mathias Bynens math...@qiwi.be wrote:
`String.prototype.codePointAt` or `String.prototype.at` come in handy in
case you only need to get the first code point or symbol in a string
On 19 Oct 2013, at 12:54, Domenic Denicola dome...@domenicdenicola.com wrote:
My proposed cowpaths:
```js
Object.mixin(String.prototype, {
realCharacterAt(i) {
let index = 0;
for (var c of this) {
if (index++ === i) {
return c;
}
}
}
get realLength() {
On 14 Oct 2013, at 23:21, Erik Arvidsson erik.arvids...@gmail.com wrote:
I'm concerned about the latest version of this on the wiki. The
edition parameter requires that we ship 2 tables today. This seems
like it might change to 3 in ES7 and n in ES(n+4). I think the only
reasonable
On 24 Oct 2013, at 16:02, Claude Pache claude.pa...@gmail.com wrote:
Therefore, I propose the following basic operations to operate on grapheme
clusters:
Out of curiosity, is there any programming language that operates on grapheme
clusters (rather than code points) by default? FWIW, code
On 24 Oct 2013, at 16:22, Anne van Kesteren ann...@annevk.nl wrote:
On Thu, Oct 24, 2013 at 3:02 PM, Claude Pache claude.pa...@gmail.com wrote:
As a side note, I ask whether the `String.prototype.symbolAt
`/`String.prototype.at` as proposed in a recent thread,
and the
On 26 Oct 2013, at 14:39, Bjoern Hoehrmann derhoe...@gmx.net wrote:
* Norbert Lindenberg wrote:
On Oct 25, 2013, at 18:35 , Jason Orendorff jason.orendo...@gmail.com
wrote:
UTF-16 is designed so that you can search based on code units
alone, without computing boundaries. RegExp searches
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
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
One more related question: are these three regular expression literals
equivalent?
1. `/[-]/u`: raw astral symbols
2. `/[\u{1F4A9}-\u{1F4AB}]/u`: astral symbols represented using Unicode code
point escape sequences
3. `/[\uD83D\uDCA9-\uD83D\uDCAB]/u`: astral symbols represented as a surrogate
On 22 Nov 2013, at 11:20, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
Did you check the ES6 draft grammar{1]? The answer to that should be fairly
obvious there and if it isn't it would be good to know so we can try to make
it clearer in the spec.
[1]:
From http://ecma-international.org/ecma-262/5.1/#sec-15.3.4.3 and
http://ecma-international.org/ecma-262/5.1/#sec-15.3.4.4:
The `thisArg` value is passed without modification as the `this` value. This
is a change from Edition 3, where a `undefined` or `null` `thisArg` is
replaced with the
Turns out this is a bug in the spec:
https://bugs.ecmascript.org/show_bug.cgi?id=2370
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Both `String.prototype.startsWith` and `String.prototype.endsWith` throw a
`TypeError` if the first argument is a RegExp:
Throwing an exception if the first argument is a RegExp is specified in order
to allow future editions to define extends that allow such argument values.
However, this is
On 18 Dec 2013, at 23:02, Benjamin (Inglor) Gruenbaum ing...@gmail.com wrote:
If anything, I'd expect all of them to throw when passed multiple arguments
for forward compatibility. It might be useful to check multiple values in
contains/endsWith/startsWith or constrain it in some way.
The
I was wondering who was in charge of the ecmascript.org web site.
$ whois ecmascript.org
[snip]
Registrant Organization:Mozilla Corporation
Registrant Street: 650 Castro St Ste 300
Registrant City:Mountain View
Registrant State/Province:CA
Registrant Postal Code:94041
Registrant Country:US
On 10 Feb 2014, at 10:30, Michael Dyck jmd...@ibiblio.org wrote:
On a more meta level, do the process plans for ES7 include any new
mechanisms for:
(a) submitting comments on spec drafts, or
(b) reducing the number of errors in spec drafts to begin with?
If only the spec were maintained in a
Allen mentioned that `String#at` might not make it to ES6 because nobody in
TC39 is championing it. I’ve now asked Rick if he would be the champion for
this, and he agreed. (Thanks again!)
Looking over the ‘TC39 progress’ document at
On 14 Feb 2014, at 11:11, Domenic Denicola dome...@domenicdenicola.com wrote:
This was the method that was only useful if you pass `0` to it?
I’ll just avoid the infinite loop here by pointing to earlier posts in this
thread where this was discussed before:
On 14 Feb 2014, at 11:14, C. Scott Ananian ecmascr...@cscott.net wrote:
Note that `Array.from(str)` and `str[Symbol.iterator]` overlap
significantly. In particular, it's somewhat awkward to iterate over
code points using `String#symbolAt`; it's much easier to use
`substr()` and then use the
On 14 Feb 2014, at 19:59, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
It's a really high bar to get over that closed gate. Unless the exclusion of
a feature was a mistake […] I don't think we should be talking about adding
it to ES6.
It does feel like a mistake to me to introduce
On 20 Feb 2014, at 21:20, Eric Elliott e...@ericleads.com wrote:
Object literals are already a great alternative to switch in JS:
var cases = {
val1: function () {},
val2: function () {}
};
cases[val]();
In that case, you’d need a `hasOwnProperty` check to make sure you’re not
On 5 Mar 2014, at 17:19, Domenic Denicola dome...@domenicdenicola.com wrote:
Personally I think the more useful model to follow than
`String.prototype.contains` is `Set.prototype.has`.
But then DOM4 `DOMStringList` would still have its own `contains` _and_ the
`has` it inherits from
On 21 Mar 2014, at 16:38, C. Scott Ananian ecmascr...@cscott.net wrote:
```js
function replaceTitle(title, str) {
return str.replace(new RegExp(title), ...);
}
```
There ought to be a standard simple way of writing this correctly.
I’ve used something like this in the past:
To convert from base64 to ASCII and vice versa, browsers have had global `atob`
and `btoa` functions for a while now. At the moment, these are defined in the
HTML standard: http://whatwg.org/html/webappapis.html#atob
However, such utility methods are not only useful in browsers. How about
On 5 May 2014, at 00:00, Andrea Giammarchi andrea.giammar...@gmail.com wrote:
as generic global utility it would be also nice to make it compatible with
all strings.
For backwards compatibility reasons, `atob`/`btoa` should probably continue to
work in exactly the same way they work now (i.e
On 5 May 2014, at 10:48, Claude Pache claude.pa...@gmail.com wrote:
In my view, if `atob` and `btoa` were to enter in ES, it should be in
Appendix B (the deprecated legacy features of web browsers), where it would
be in good company with the other utility that does an implicit confusion
On 5 May 2014, at 20:22, Andrea Giammarchi andrea.giammar...@gmail.com wrote:
@mathias didn't mean to change atob and btoa rather add two extra methods
such encode/decode for strings (could land without problems in the
String.prototype, IMO) with less silly names whatever definition of silly
On Fri, May 9, 2014 at 1:44 AM, John-David Dalton
john.david.dal...@gmail.com wrote:
Should I create a spec bug for tracking this?
Please do.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Previous discussion on this topic:
http://esdiscuss.org/topic/array-prototype-last
We should look at how existing utility libraries handle this behavior and base
any proposals on that IMHO. Underscore and Lo-Dash have
[`_.first`](http://lodash.com/docs#first) and
On 6 Jun 2014, at 01:15, Axel Rauschmayer a...@rauschma.de wrote:
It’d be nice to have a built-in way for comparing numbers, e.g. when sorting
arrays.
```js
// Compact ECMAScript 6 solution
// Risk: number overflow
[1, 5, 3, 12, 2].sort((a,b) = a-b)
// Proposed new function:
[1, 5,
On 13 Jun 2014, at 18:15, Domenic Denicola dome...@domenicdenicola.com wrote:
IMO it would be a good universe where `module` had the following things
`script` has:
- Does not require escaping' in any contexts.
- Terminates when seeing `/module` + extra chars. (Possibly we could do
On 1 Aug 2014, at 09:25, Carl Shapiro carl.shap...@gmail.com wrote:
Thanks for the suggestion.
As Ray pointed out, the Math package in Java still has its accuracy
requirements specified and so it is not analogous to the current status of
Math package in ES6. Also, the StrictMath package
On 5 Aug 2014, at 02:41, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
there is already a bug open on this
https://bugs.ecmascript.org/show_bug.cgi?id=2792
Older bug report: https://bugs.ecmascript.org/show_bug.cgi?id=1553
We previously discussed this up at the April TC39 meeting:
On 5 Aug 2014, at 08:40, Mathias Bynens math...@qiwi.be wrote:
On 5 Aug 2014, at 02:41, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
there is already a bug open on this
https://bugs.ecmascript.org/show_bug.cgi?id=2792
Older bug report: https://bugs.ecmascript.org/show_bug.cgi?id=1553
On 4 Aug 2014, at 18:55, Jason Orendorff jason.orendo...@gmail.com wrote:
We're talking about something different here, legacy *decimal* integer
literals starting with 0 and containing 8 or 9. As far as I know, no
version of ES has ever permitted this kind of nonsense, but supporting
it is
On 5 Aug 2014, at 16:20, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
We're only talking about Annex B, non-strict. Right?
All engines are going to implement this anyway, so why make it Annex B only? I
wouldn’t restrict it to non-strict mode either, as this decision seems to be
purely
On 5 Aug 2014, at 16:56, Alex Kocharin a...@kocharin.ru wrote:
What about allowing one-digit numbers with leading zeroes? 07 equals to 7
no matter whether it parsed as an octal or as a decimal. Thus, no harm there.
That wouldn’t solve the problem. Consider e.g. `01234567` (i.e. `342391`) vs.
On 5 Aug 2014, at 17:05, Mark S. Miller erig...@google.com wrote:
Because of compatibility constraints, JS history can generally proceed only
in an additive manner, which means a steady degradation of quality along the
simplicity dimension. An opt-in mode switch is the only way to escape
On 5 Aug 2014, at 17:05, Mark S. Miller erig...@google.com wrote:
Strict mode should not accept octal literals.
The literals under discussion (e.g. `08` and `09`) are not octal literals.
___
es-discuss mailing list
es-discuss@mozilla.org
On 5 Aug 2014, at 17:19, Mark S. Miller erig...@google.com wrote:
On Tue, Aug 5, 2014 at 8:17 AM, Mathias Bynens math...@qiwi.be wrote:
The literals under discussion (e.g. `08` and `09`) are not octal literals.
Strict mode should reject these even more vehemently! (Allen, can we have
On 5 Aug 2014, at 18:30, Rick Waldron waldron.r...@gmail.com wrote:
- Spread now works on strings `var codeUnits = [...this is a string]`
The code example implies it results in an array of strings, one item for each
UCS-2/UTF-16 code unit. Shouldn’t this be symbols matching whole Unicode code
On 7 Aug 2014, at 02:46, Bill Frantz fra...@pwpconsult.com wrote:
On Tue, Aug 5, 2014 at 7:56 AM, Mathias Bynens math...@qiwi.be wrote:
...
In section 11.8.3 (Numeric Literals), the definition for
`DecimalIntegerLiteral` should somehow be tweaked to match that of
`DecimalDigits
Claude Pache proposed the following spec patch:
https://bugs.ecmascript.org/show_bug.cgi?id=2792#c11
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Norbert’s original proposal for the `u` flag
(http://norbertlindenberg.com/2012/05/ecmascript-supplementary-characters/#RegExp)
mentioned the following:
Possibly the definition of the character classes `\d\D\w\W\b\B` is extended
to their Unicode extensions, such as all characters in the
reports welcome.)
On Aug 25, 2014, at 1:59 , Mathias Bynens math...@qiwi.be wrote:
Norbert’s original proposal for the `u` flag
(http://norbertlindenberg.com/2012/05/ecmascript-supplementary-characters/#RegExp)
mentioned the following:
Possibly the definition of the character classes `\d\D\w
1 - 100 of 129 matches
Mail list logo
