Darien Valentine (2017-12-13T02:38:20.000Z)
> [...] in most cases number suffixes/literals/syntaxes are just sugar, and
must
> be processed at compile-time (0xFF000000 syntax is also just sugar).

Probably everybody has a different idea of what "sugar" is, but to me
something is sugar when it can be _desugared_ to some more complex thing
underlying it. I’d just call dec/hex/oct/bin "notations" — even though the
choice of numeric notation doesn’t contribute to runtime semantics, "0xFF"
doesn’t desugar to "255" (or 0XFF, or 255.0, or 0o377, etc).

> [...] to make this proposal useful - JS also need to support operators
> overloading, without operator overloading do something useful while
writing
> 10px + 1em is impossible, so it decreases usability of this innovation to
just
> another way of calling function(for now).

If it were just a static multiplier value (e.g., 1s evaluating to 1000),
then I’d imagine the suffix data wouldn’t be available at runtime; it would
occur during parsing and just be an (alternative notation / sugar). However
if you’re envisioning it as something that interacts with operators at
runtime, that would seem to be a very different thing; the type in question
could no longer be "number".

The static-only version doesn’t look good to me because it sits on a lot of
syntactic space and miscommunicates the nature of the values. For example,
many APIs accept seconds, not milliseconds. So say somebody reads that in
the docs for something, say "maxAge accepts a value in seconds". How
surprising then that when they dutifully provide `{ maxAge: 30s }`, it sets
it to a bit over eight hours :D

The runtime version seems likely to create more confusion than not, too.
The example you gave — `10px + 1em` — demonstrates how that might go. One
might expect that to work because css’s `calc` can do it. But the browser
knows what the current value of `em` for the node in question is. Even if
it somehow knew what the contextual relationship between px and em was,
it’s not clear to me what that’s actually supposed to evaluate to.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20171212/509f2782/attachment.html>
valentinium at gmail.com (2017-12-13T02:39:58.402Z)
> [...] in most cases number suffixes/literals/syntaxes are just sugar, and must
> be processed at compile-time (0xFF000000 syntax is also just sugar).

Probably everybody has a different idea of what "sugar" is, but to me
something is sugar when it can be _desugared_ to some more complex thing
underlying it. I’d just call dec/hex/oct/bin "notations" — even though the
choice of numeric notation doesn’t contribute to runtime semantics, "0xFF"
doesn’t desugar to "255" (or 0XFF, or 255.0, or 0o377, etc).

> [...] to make this proposal useful - JS also need to support operators
> overloading, without operator overloading do something useful while writing
> 10px + 1em is impossible, so it decreases usability of this innovation to just
> another way of calling function(for now).

If it were just a static multiplier value (e.g., 1s evaluating to 1000),
then I’d imagine the suffix data wouldn’t be available at runtime; it would
occur during parsing and just be an (alternative notation / sugar). However
if you’re envisioning it as something that interacts with operators at
runtime, that would seem to be a very different thing; the type in question
could no longer be "number".

The static-only version doesn’t look good to me because it sits on a lot of
syntactic space and miscommunicates the nature of the values. For example,
many APIs accept seconds, not milliseconds. So say somebody reads that in
the docs for something, "maxAge accepts a value in seconds". How
surprising then that when they dutifully provide `{ maxAge: 30s }`, it sets
it to a bit over eight hours :D

The runtime version seems likely to create more confusion than not, too.
The example you gave — `10px + 1em` — demonstrates how that might go. One
might expect that to work because css’s `calc` can do it. But the browser
knows what the current value of `em` for the node in question is. Even if
it somehow knew what the contextual relationship between px and em was,
it’s not clear to me what that’s actually supposed to evaluate to.