Untagged variants: consider regexp as an object type. #6296
Conversation
cristianoc
force-pushed
the
regexp_as_object
branch
from
c06e29e
to
983a9e7
Compare
CHANGELOG.md
Outdated
| @@ -16,6 +16,7 @@ | |||
|
|
|||
| - Introduced a new `%ffi` extension (*experimental* - not for production use!) that provides a more robust mechanism for JavaScript function interoperation by considering function arity in type constraints. This enhancement improves safety when dealing with JavaScript functions by enforcing type constraints based on the arity of the function. https://github.com/rescript-lang/rescript-compiler/pull/6251 | |||
| - Extended untagged variants with function types. https://github.com/rescript-lang/rescript-compiler/pull/6279 | |||
| - Untagged variants: consider regexp as an object type. https://github.com/rescript-lang/rescript-compiler/pull/6296 | |||
There was a problem hiding this comment.
This needs to go to beta.3 actually, I will do the PR for preparing beta.3 after I have got the "publish to npm on tag build" stuff working.
| @@ -117,7 +117,7 @@ let type_is_builtin_object (t : Types.type_expr) = | |||
| match t.desc with | |||
| | Tconstr (path, _, _) -> | |||
| let name = Path.name path in | |||
| name = "Js.Dict.t" || name = "Js_dict.t" | |||
| name = "Js.Dict.t" || name = "Js_dict.t" || name = "Js.Re.t" || name = "RescriptCore.Re.t" | |||
There was a problem hiding this comment.
For the cases when Js/Belt/RescriptCore opened globally:
| name = "Js.Dict.t" || name = "Js_dict.t" || name = "Js.Re.t" || name = "RescriptCore.Re.t" | |
| name = "Js.Dict.t" || name = "Js_dict.t" || name = "Dict.t" || "RescriptCore.Dict.t" || name = "Js.Re.t" || name = "Re.t" || name = "RescriptCore.Re.t" |
There was a problem hiding this comment.
That's not how it works. Internally, you still get the full path.
There was a problem hiding this comment.
I'm talking about the case when there's a custom implementation of a module from stdlib.
There was a problem hiding this comment.
Got it. That is another topic, which is pretty interesting, and worth discussing in a separate issue.
Quick thoughts: assuming it's what it is just based on name sounds risky, and perhaps not even necessary.
Topic: how to represent that a type is an object type.
- For untagged variants, it's useful to express more patterns
- For options, it helps as they can be represented unboxed
- For the language: the current mechanism
{..}is both obscure and not very useful/flexible.
For points 1 and 2, one can already recognise when a type used is defined as an object type (unless I'm misremembering -- check).
For abstract types, one could e.g. use an annotation @object.
For 3, perhaps one could use a new built-in type object<_> with some operations on it. E.g. creation will return object<'a> for an arbitrary 'a.
There has to be a mechanism to cast actual objects into the type object<...>.
The Dict module might look very different if this is used.
So having an object<...> type is only one possibility. But if one embraces this possibility then the case of the abstract types would work like this:
type someSecretType
type someAbstractObject = object<someSecretType>
without the need for any @object annotation.
cristianoc
force-pushed
the
regexp_as_object
branch
from
983a9e7
to
482c09c
Compare
|
@DZakh would you check that this works for you (installing the package produced by CI when it's done). |
|
@cristianoc I've tested. Works great ✨ |
Fixes #6140