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

Allow constraints for non-primitive types to be evaluable at compile-time #147

Closed
Iltotore opened this issue Jun 25, 2023 · 4 comments · Fixed by #266
Closed

Allow constraints for non-primitive types to be evaluable at compile-time #147

Iltotore opened this issue Jun 25, 2023 · 4 comments · Fixed by #266
Labels
breaking changes Changes that break compatibility with older versions enhancement New feature or request
Milestone

Comments

@Iltotore
Copy link
Owner

This is not possible at the moment because Constraint#apply's parameter is not inline. Making it inline would force all children to propagate make it inline too, breaking backward compatibility.

For example, this:

val x: List[String] :| FixedLength[3] = List("a", "b", "c")

is not verifiable at compile-time but this will be easily doable once value in Constraint#apply is inline.

@Iltotore Iltotore added enhancement New feature or request breaking changes Changes that break compatibility with older versions labels Jun 25, 2023
@Iltotore Iltotore added this to the 3.0.0 milestone Jun 25, 2023
@Iltotore Iltotore changed the title Allow non-primitive types constraints to be evaluable at compile-time Allow constraints for non-primitive types to be evaluable at compile-time Jun 25, 2023
@KaranAhlawat
Copy link

If I understand correctly, right now the snippet you shared does not evaluate at compile-time.
So, if we were to use it as an IronType, we would necessarily have to write List(...).refine or some equivalent method, yes?

@Iltotore
Copy link
Owner Author

Yes. It is currently not possible to use the compile-time conversion with such type.

The fix is simple but would introduce a pretty big compatibility break. Therefore, it will only appear when 3.0.0 will be released.

@Iltotore
Copy link
Owner Author

While working on 2.6.0, I noticed that Dotty might not fully reduce non-primitive expressions. This might be due to the missing inline keyword in Constraint#apply or not. It needs further investigation.

@Iltotore
Copy link
Owner Author

The solution I am currently implementing seems to work 🎉. The compatibility break should be minimal and I'll try to make a Scalafix rule to mitigate it.

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.

2 participants