To be honest, introducing new throw-on-invalid value behaviour to existing
function that didn't throw before looks rather like a bad design for me.
Personally I wouldn't abandon accept-anything behaviour of Number, but
rather add method Number.from that will throw on all values that shouldn't
be coerced to number.
On 15 Oct 2016 1:23 a.m., "Allen Wirfs-Brock" <al...@wirfs-brock.com> wrote:
> > On Oct 14, 2016, at 11:02 AM, Claude Pache <claude.pa...@gmail.com>
> >> Le 11 oct. 2016 à 11:07, medikoo <medikoo+mozilla....@medikoo.com> a
> écrit :
> >> I was searching the archived but wasn't able to find the answer.
> >> What's the reasoning behind having Number(symbol) crash instead of
> >> NaN (as it's in case all other non-coercible values?). It feels not
> >> consistent.
> >> If someone can point me to some discussion that provided the reasoning
> >> be grateful
> > I believe that the reason of the inconsistency is more an accident of
> history in the development of ES6 than a well-reasoned design decision.
> Here is my understanding:
> No this was an intentional design decision. There is no obvious or
> natural Number value corresponding to symbol values. Rather than inventing
> some arbitrary conversion rule (for example producing NaN) TC39 choose to
> throw an exception for such conversions as they are a clear manifestation
> of some sort of program bug.
> Note that the coercion rules for the original JS primitive types were
> mechanism and hence all operations were required to produce some value.
> Throwing exceptions for unreasonable Symbol coercions is intentionally
> inconsistent with the handling of the original primitive coercions and is
> intended to set a new precedent that will be applied to any other new
> primitive types that might be added to ES in the future.
> es-discuss mailing list
es-discuss mailing list