Closed bobzhang closed 1 year ago
Sorry @bobzhang if #1
is accepted in the future and compiles to 1
can we keep #"1"
to compile to "1"
(even though I understand it's an escape hatch it's a neat one ^^)?
There are several reasons for that, but the main one is backward compatibility (actually we do use #"number"
here and there already 😁).
I wonder, why will numeric variants be compiled to numbers ?
@gaku-sei it is to provide good interop with JS API which expects enums or return enums. There is currently no easy way to do this without a conversion; and it is a pain point for production users. What's your use case for making #"1" to "1"?
@bobzhang is there a reason we restrict this to non-float numbers? (I'll document this for posteriority)
@IwanKaramazow the main use case is for passing and receiving enums.
This is is the quote from some users:
i think positive integers covers 99% of our use cases
Float can be a bit tricky, since 0.33
may not be representable in IEEE 754.
FYI: https://github.com/rescript-lang/rescript-compiler/blob/master/jscomp/ext/ext_string.ml#L510 this is what we used to determine if it is the hash number.
Things could be done in the front-end:
#1
#"1"
since this can be confusingIn the future, we could support things like #0x01
(the hex format) which should be in no conflict with what we have right now. Note this addition is also a good example to demonstrate the value of rescript syntax.
Thanks for the background, will implement.
There is currently no easy way to do this without a conversion; and it is a pain point for production users.
Makes actually, absolutely makes sense.
What's your use case for making #"1" to "1"?
We use to interface with tailwind and concat the poly variant with some other string. In that case the new syntax happens to work, but I was concerned that some cases wouldn't work (hence the idea to differentiate #"1"
and #1
as it seems they cover 2 different use cases 😕
@gaku-sei I think this still works since you mentioned concatenation.
1+"px" === "1" + "px"
Yeah kinda agree that maybe #"1" should be supported. Otherwise a bit inconsistent
We could support #"1" syntactically, but it will be encoded as 1, so it may bring confusion instead of consistency. Note for structural types, the encoding has to be simple and consistent.
Oh, if #"1" is encoded as 1 then nevermind. Would rather have a good error message or formatted format to #1. But I was saying that it was confusing to not support #"1" as "1"
i think positive integers covers 99% of our use cases
I'm trying to create a tool to generate ReScript bindings from TypeScript type definitions (.d.ts
), and I've been encountering so many negative integers, even in popular packages:
typescript
: https://github.com/microsoft/TypeScript/blob/9d443b76aac0832d7f3c890441264d39307fe31a/lib/typescript.d.ts#L1714node
: https://github.com/DefinitelyTyped/DefinitelyTyped/blob/ee4131447a3b01d3a0463e2d2794df0302b6e711/types/node/v14/tty.d.ts#L16semver
: https://github.com/DefinitelyTyped/DefinitelyTyped/blob/f7ec78508c6797e42f87a4390735bc2c650a1bfd/types/semver/classes/semver.d.ts#L27It seems people often use 1 | -1
to indicate left/right or positive/negative, 1 | 0 | -1
to represent larger/equal/smaller, and -1
, -2
, ... for special/erroneous cases, which should be better represented as type rather than making it just int
.
Also, it kind of contradicts with the fact @deriving(jsConverter)
for non-poly variant supports negative values.
@deriving(jsConverter)
can be used as a workaround, but it introduces an unnecessary variant type each time something like 1 | 0 | -1
is used.
The rescript-lang/syntax repo is obsolete and will be archived soon. If this issue is still relevant, please reopen in the compiler repo (https://github.com/rescript-lang/rescript-compiler) or comment here to ask for it to be moved. Thank you for your contributions.
Note we are planning to provide numeric poly var support so that
#"1"
is going to be compiled as 1 instead of "1"Ideally, we should allow user to write
#1
directly since it is compiled to 1 instead of "1" Some more context are provided here: https://github.com/rescript-lang/rescript-compiler/issues/5026For the formal rules it would be:
Also an extra overflow check is needed