Skip to content

Coercion improvements #7507

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
3 tasks
zth opened this issue May 23, 2025 · 5 comments
Open
3 tasks

Coercion improvements #7507

zth opened this issue May 23, 2025 · 5 comments

Comments

@zth
Copy link
Collaborator

zth commented May 23, 2025

Listing some ideas for improvements to coercion/subtyping.

  • A variant can be coerced to a polyvariant if the polyvariant is closed and the runtime representation matches
  • Investigate dicts - what can be coerced?
  • Handle more coercion + unboxed variants. For example. "hello" :> JSON.t and 1. :> JSON.t works, but not 1 :> JSON.t, true :> JSON.t or dict{"test": "hello"} :> JSON.t
@nojaf
Copy link
Collaborator

nojaf commented May 23, 2025

A variant can be coerced to a polyvariant if the polyvariant is closed and the runtime representation matches

Not sure if this example falls under that, but it would be great if we could do the following:

let f = (v:s) => ()

type t = | Foo | Bar | Meh

let _ = f(Foo) // without writing `Foo :> string`

@zth
Copy link
Collaborator Author

zth commented May 23, 2025

I don't think that example is complete...? What is s?

@nojaf
Copy link
Collaborator

nojaf commented May 23, 2025

Oh, sorry s for string.

@zth
Copy link
Collaborator Author

zth commented May 23, 2025

Ah right. So you essentially mean implicit coercion. No, that's something we've intentionally decided against. We want any type coercion to be explicit. There are many reasons:

  1. You might not actually want a type coercion in various contexts, since types have meaning depending on context
  2. It needs to be clear from the code where coercion is happening
  3. Coercion can come with some perf loss in the type checking if the types are complex, so doing it should be explicit

@nojaf
Copy link
Collaborator

nojaf commented May 23, 2025

Got it, thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants