Skip to content
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

Make RefinedTypeOps blackbox #254

Closed
Iltotore opened this issue Jul 30, 2024 · 0 comments · Fixed by #261
Closed

Make RefinedTypeOps blackbox #254

Iltotore opened this issue Jul 30, 2024 · 0 comments · Fixed by #261
Assignees
Labels
breaking changes Changes that break compatibility with older versions enhancement New feature or request
Milestone

Comments

@Iltotore
Copy link
Owner

Following #250

RefinedTypeOps leaks its implementation in apply method, forcing users to have io.github.iltotore.iron.autoRefine in their scope.

opaque type PosInt = Int :| Positive
object PosInt extends RefinedTypeOps[Int, Positive, PosInt]

This is because apply requires a A :| C and relies on autoRefine to refine the non-iron values at compile-time.

A potential solution would be to separate apply(A :| C) into two methods (like it used to in earlier versions):

  • apply(A) checking the passed value at compile-time or aborts (like autoRefine but embedded in the method)
  • fromIronType(A :| C), equivalent to current apply

This way, it is possible to make compile-time checked newtype instances without requiring Iron in the scope so libraries can use Iron in their datatypes without exposing it.

While harder to achieve, finding a solution with only an apply method might be doable by checking if the passed value's type is an Iron type:

inline def apply[A1 <: A](inline value: A1): T =
  inline if macros.isIronType[A1] then value.asInstanceOf
  else
    macros.assertCondition(...)
    value.asInstanceOf

This approach has the pro of being source-retrocompatible but it has two cons:

  • It might have some corner cases due to macros/inlines
  • apply's signature is less trivial

Since it is pretty straightforward to rewrite the code to fit the new definition of apply or even make a Scalafix rewriting rule, I'm in favor of the first approach which is simpler and less prone to some metaprogramming corner cases.

@Iltotore Iltotore added enhancement New feature or request breaking changes Changes that break compatibility with older versions labels Jul 30, 2024
@Iltotore Iltotore added this to the 3.0.0 milestone Jul 30, 2024
@Iltotore Iltotore self-assigned this Aug 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking changes Changes that break compatibility with older versions enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant