-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Expand compiletime.ops
#13400
Expand compiletime.ops
#13400
Conversation
6d7c825
to
9570a88
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In general, this looks good to me! But seeing that I'm not currently very active in the day-to-day Dotty development, I'm adding @OlivierBlanvillain as a reviewer, so that we have the approval of one of the core maintainers too.
I do also have a higher-level question about Strings in particular: should we aim to have full support of all the methods in java.lang.String
? We're missing methods like charAt
, startsWith
, etc. Some of these methods also take objects, such as format
which takes a String
or a Locale
for the locale
parameter. We can't support Locale
, but we could support String
.
I currently do not support |
@smarter since we are currently in RC1, can we still get this in 3.1.0 if there will be RC2? |
No, only fixes to regressions are backported into the release branch. |
Though the added operations could be added in 3.1.1 as |
OK, then the deprecation for |
I am very interested by this PR, I was going to add the same fix for getting the underlying types of termrefs 😃 What is the status? Could we merge this soon or are there any blockers? |
It needs to be reviewed and the added definitions need to be marked |
I'll try to complete this soon. |
This PR would be very useful to me. I'd need it to cross build |
… termref type not being considered. fix check file more ops wip Added ops.float and ops.double
Update MiMaFilters.scala Update MiMaFilters.scala
Main changes: * Apply common protection against wrong number of arguments. * Exception in an operation is converted into a type error.
ea00474
to
762d90e
Compare
Ready for review @OlivierBlanvillain |
BTW: I think this PR really brings up a weakness of match types: we shouldn't need to have a PR in the compiler to implement these functions. It seems like if metaprogramming could be combined with match types, then you could implement these functions in your own code. That seems like it would be a promising area. |
Hence, this Pre-SIP: https://contributors.scala-lang.org/t/pre-sip-custom-dependent-operation-types/5236/14 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
@@ -70,8 +73,6 @@ object Test { | |||
|
|||
val t48: ToString[213] = "213" | |||
val t49: ToString[-1] = "-1" | |||
val t50: ToString[0] = "-0" // error | |||
val t51: ToString[200] = "100" // error |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's wrong with that test?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's wrong with that test?
Nothing was wrong. At first I wanted to remove all int.ToString
tests because it was deprecated, but then I decided not to remove the tests until it was removed completely. So perhaps I forgot to bring these tests back as well. I could change the commit, but I don't think it's a big deal.
@johnynek IMO it's perfectly normal to require compiler support for type-level operations on primitive types. In the long term, the goal should be to be on par with term-level operations on primitives. If somebody is interested in working on a follow-up PR to add support for |
9594465
to
3083cae
Compare
@@ -181,4 +183,47 @@ object int: | |||
* ``` | |||
* @syntax markdown | |||
*/ | |||
@deprecated("Use compiletime.ops.any.ToString instead.","3.2.0") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@soronpo I think this warning will be shown even before 3.2.0 is released which means users will have to choose between a deprecated and an experimental definition, could you comment out the deprecated annotation for now?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@smarter why would it show before? The version is specified. Is there a bug in @deprecated
? If so, we should fix this instead.
This PR expands
compiletime.ops
as follows:ops.string.{Length, Substring, Matches}
ops.int.NumberOfLeadingZeros
ops.long
as equivalent toops.int
, but forLong
operationsops.float
andops.double
ops.any.IsConst
ops.int.ToString
(from 3.2.x) and moves it toops.any.ToString
one.type + two.type
, whereone
andtwo
are final vals).