Re: RFR: 8279986: methods Math::asXExact for safely checked primitive casts
When they return, these methods meet the property, even for -0.0 provided the underlying eq is floating-point ==, not *::compare: -0.0 -> 0 -> 0.0 and there is a loss of information about the sign bit. However, as currently stated, the property is not 100% correct. For example, (long) (double) Long.MAX_VALUE == Long.MAX_VALUE evaluates to true but you cannot conclude that Long.MAX_VALUE is converted exactly to a double: indeed, it is not. The methods deal with these special cases and throw. The tests for pattern matching should deal with special cases as well. From: Brian Goetz Date: Wednesday, 25 May 2022 at 17:18 To: Raffaello Giulietti , core-libs-dev@openjdk.java.net Subject: Re: RFR: 8279986: methods Math::asXExact for safely checked primitive casts Another way to evaluate answers here is: are we inventing new relations, or merely clarifying old ones? The latter is often more desirable. For example, we might say that x:X can be converted exactly to Y, for primitive X and Y, iff: eq( (X) (Y) x, x ) where `eq` is `==` for non-floating primitive types, and derived from Float::compare and Double::compare for floating point. This means we are not inventing any new conversions or comparisons, but merely combining ones we already have in the language/platform in a convenient way. Do the toXExact methods you've defined have this characteristic? (Though, while this is often the best starting place, it is not always a slam-dunk answer; sometimes there are good reasons to depart from existing relations, but we should be explicit about what those are.) On 5/25/2022 9:46 AM, Raffaello Giulietti wrote: The motivation behind this PR is not driven by pattern matching: John Rose (the reporter of the JBS issue) is concerned about having safer casts that, in addition, can be JITted to efficient code. But I get your point that having non-throwing tests better serves pattern matching. However, I’m not sure that pattern matching alone would remove the more general need for the proposed methods. As for the controversial question about -0.0, as you note any proposal will kind of suck. With “safer” cast methods we can have two (or even more) variants. In the context of primitive pattern matching (including the relevant material in the JLS), however, it would be probably much simpler to allow for matches between integral types on one side and for matches between floating-point types on the other side, but not a mix. The nuisance with -0.0 and other special values would disappear altogether. Thus, while examples like if (anIntExpression instanceof byte b) and if (aDoubleExpression instanceof float f) make perfect sense, would an example like if (aDoubleExpression instanceof short s) be pragmatically reasonable? IIRC, the discussions about “Primitive type patterns” and “Evolving past reference type patterns” in the amber-spec-experts mailing list of April 2022 don’t even mention the mixed integral/floating-point case. Greetings Raffaello From: core-libs-dev <mailto:core-libs-dev-r...@openjdk.java.net> on behalf of Brian Goetz <mailto:brian.go...@oracle.com> Date: Tuesday, 24 May 2022 at 00:09 To: Raffaello Giulietti <mailto:d...@openjdk.java.net>, core-libs-dev@openjdk.java.net<mailto:core-libs-dev@openjdk.java.net> <mailto:core-libs-dev@openjdk.java.net> Subject: Re: RFR: 8279986: methods Math::asXExact for safely checked primitive casts This work is quite timely as we are now paving the way for primitive type patterns over in Project Amber, and also has a nontrivial connection with Valhalla. If you'll pardon a brief digression... Instanceof and casting work together in a familiar way: before you cast, you first ask instanceof -- but this is restricted currently to reference types. But the pattern is obvious: instanceof is the precondition check for casting, which asks: "If I made this cast, would I like the answer." There are currently two reasons to not like the answer: a CCE, or the operand is null (because, even though the cast would succeed, if you tried to use it as a member of that type, you wouldn't like the answer then.) If we wanted to extend `instanceof` to primitive types, we are asking the same question: if I were to cast to this type, would I like the answer. And casts involving primitives give us two more reasons to not like the answer: an NPE (due to unboxing), or loss of precision. Which means that we have to specify in JLS 5.1 what cast with loss of precision means. At the very least, we will want to align this work with that; the asXExact should be able to say "throws if the cast would lose precision", where "lose precision" is precisely defined by the JLS. Separately, Project Valhalla will let us define new primitive-like types, such as HalfFloat and SuperLong. Conversions between primitives are currently specified in a complex table in JLS 5.1. But sur
Re: RFR: 8279986: methods Math::asXExact for safely checked primitive casts
Another way to evaluate answers here is: are we inventing new relations, or merely clarifying old ones? The latter is often more desirable. For example, we might say that x:X can be converted exactly to Y, for primitive X and Y, iff: eq( (X) (Y) x, x ) where `eq` is `==` for non-floating primitive types, and derived from Float::compare and Double::compare for floating point. This means we are not inventing any new conversions or comparisons, but merely combining ones we already have in the language/platform in a convenient way. Do the toXExact methods you've defined have this characteristic? (Though, while this is often the best starting place, it is not always a slam-dunk answer; sometimes there are good reasons to depart from existing relations, but we should be explicit about what those are.) On 5/25/2022 9:46 AM, Raffaello Giulietti wrote: Themotivation behind this PR isnot driven by pattern matching:John Rose (the reporter of the JBS issue) is concerned about having safer casts that, in addition, can be JITted to efficient code. But I get your point that having non-throwing testsbetter serves pattern matching.However, I’m not sure that pattern matching alone would remove the more general need for the proposed methods. As for the controversial question about -0.0, as you note any proposal will kind of suck. With “safer” cast methods we can have two (or even more) variants. In the context of primitive pattern matching (including the relevant material in the JLS), however, it would be probably much simpler to allow for matches between integral types on one side and for matches between floating-point types on the other side, but not a mix. The nuisance with -0.0 and other special values would disappear altogether. Thus, while examples like if (anIntExpression instanceof byte b) and if (aDoubleExpression instanceof float f) make perfect sense, would an example like if (aDoubleExpression instanceof short s) be pragmatically reasonable? IIRC, the discussions about “Primitive type patterns” and “Evolving past reference type patterns” in the amber-spec-experts mailing list of April 2022 don’t even mention the mixed integral/floating-point case. Greetings Raffaello *From: *core-libs-dev on behalf of Brian Goetz *Date: *Tuesday, 24 May 2022 at 00:09 *To: *Raffaello Giulietti , core-libs-dev@openjdk.java.net *Subject: *Re: RFR: 8279986: methods Math::asXExact for safely checked primitive casts This work is quite timely as we are now paving the way for primitive type patterns over in Project Amber, and also has a nontrivial connection with Valhalla. If you'll pardon a brief digression... Instanceof and casting work together in a familiar way: before you cast, you first ask instanceof -- but this is restricted currently to reference types. But the pattern is obvious: instanceof is the precondition check for casting, which asks: "If I made this cast, would I like the answer." There are currently two reasons to not like the answer: a CCE, or the operand is null (because, even though the cast would succeed, if you tried to use it as a member of that type, you wouldn't like the answer then.) If we wanted to extend `instanceof` to primitive types, we are asking the same question: if I were to cast to this type, would I like the answer. And casts involving primitives give us two more reasons to not like the answer: an NPE (due to unboxing), or loss of precision. Which means that we have to specify in JLS 5.1 what cast with loss of precision means. At the very least, we will want to align this work with that; the asXExact should be able to say "throws if the cast would lose precision", where "lose precision" is precisely defined by the JLS. Separately, Project Valhalla will let us define new primitive-like types, such as HalfFloat and SuperLong. Conversions between primitives are currently specified in a complex table in JLS 5.1. But surely we will want to support primitive widening conversions between HalfFloat and float (somehow; how we do this is a separate discussion.) Which brings us back to pattern matching; narrowing casts are inherently partial, and declared patterns bring partiality into the "return type", and are the natural way (when we have it) to express things like "cast, but fail if you can't do so safely". This is preferable to throwing (which currently is the our choice.) So it might be a little unfortunate to introduce throwing toXExactly now and then have to introduce separate patterns which signal precision loss by match failure. (Though that's not the end of the world if there is some duplication.) What this says is that the current proposal of toXExact is not the primitive, because we probably wouldn't want to implement a pattern in terms of the throwing version. Converting from float/double to integral types is particularly tricky with -0.0. Both an
Re: RFR: 8279986: methods Math::asXExact for safely checked primitive casts
Themotivation behind this PR isnot driven by pattern matching:John
Rose (the reporter of the JBS issue) is concerned about having safer
casts that, in addition, can be JITted to efficient code.
Yes, of course. But also, as the platform evolves, it often happens
that the same issues arises in separate places. It would be terrible if
asXExact had a different opinion of what could be converted exactly to
an int, from the language's `instanceof int`. And similarly, it would be
unfortunate if the semantics were driven by nothing more than "who got
there first." So we frequently discover things that we thought were
independent increments of functionality, that turn out to want to be
co-designed with other things, even those not known at the time we
started. This is just how this game works.
But I get your point that having non-throwing testsbetter serves
pattern matching.However, I’m not sure that pattern matching alone
would remove the more general need for the proposed methods.
Yes, not sure either. The game here is "find the primitive"; our first
move in this game is not always the right one. So let's figure it out.
As for the controversial question about -0.0, as you note any proposal
will kind of suck. With “safer” cast methods we can have two (or even
more) variants.
Also, small changes in terminology can subtly bias our answer. Words
like "exact", "information-preserving", "loss of precision", "safe",
etc, all seem to circle the same concept, but the exact choice of
terminology -- often made at random at the beginning of an investigation
-- can bias us one way or the other. (Concrete illustration: converting
-0.0 to 0 seems questionable when your rule is "no loss of information",
but seems more ambiguous when your rule is "safe".)
In the context of primitive pattern matching (including the relevant
material in the JLS), however, it would be probably much simpler to
allow for matches between integral types on one side and for matches
between floating-point types on the other side, but not a mix. The
nuisance with -0.0 and other special values would disappear altogether.
That was my first thought as well, but then I had second thoughts, as
this seemed like wishful thinking. If we are willing to say:
long x = 7;
if (x instanceof int) { /* yes, it is */ }
then it may seem quite odd to not also say
double x = 7.0;
if (x instanceof int) { /* this too? */ }
Because, the natural way to interpret the first is "is the value on the
left representable in the type on the right." Clearly 7 is
representable as an int. But so is 7.0; we lose nothing going from
double 7.0 -> int 7 -> double 7.0. And whoosh, now we're sucked into
belly of the machine, staring down -0.0 and NaN other abominations,
questioning our life choices.
That's not to say that your initial thought is wrong, just that it will
be surprising if we go that way. Maybe surprises are inevitable; maybe
this is the least bad of possible surprises. We should eliminate the
"maybes" from this analysis first, though, before deciding.
Thus, while examples like
if (anIntExpression instanceof byte b)
and
if (aDoubleExpression instanceof float f)
make perfect sense, would an example like
if (aDoubleExpression instanceof short s)
be pragmatically reasonable?
IIRC, the discussions about “Primitive type patterns” and “Evolving
past reference type patterns” in the amber-spec-experts mailing list
of April 2022 don’t even mention the mixed integral/floating-point case.
Correct, we hadn't gotten there yet, we were still trying to wrap our
heads around how it should work in the easier cases.
Re: RFR: 8279986: methods Math::asXExact for safely checked primitive casts
The motivation behind this PR is not driven by pattern matching: John Rose (the reporter of the JBS issue) is concerned about having safer casts that, in addition, can be JITted to efficient code. But I get your point that having non-throwing tests better serves pattern matching. However, I’m not sure that pattern matching alone would remove the more general need for the proposed methods. As for the controversial question about -0.0, as you note any proposal will kind of suck. With “safer” cast methods we can have two (or even more) variants. In the context of primitive pattern matching (including the relevant material in the JLS), however, it would be probably much simpler to allow for matches between integral types on one side and for matches between floating-point types on the other side, but not a mix. The nuisance with -0.0 and other special values would disappear altogether. Thus, while examples like if (anIntExpression instanceof byte b) and if (aDoubleExpression instanceof float f) make perfect sense, would an example like if (aDoubleExpression instanceof short s) be pragmatically reasonable? IIRC, the discussions about “Primitive type patterns” and “Evolving past reference type patterns” in the amber-spec-experts mailing list of April 2022 don’t even mention the mixed integral/floating-point case. Greetings Raffaello From: core-libs-dev on behalf of Brian Goetz Date: Tuesday, 24 May 2022 at 00:09 To: Raffaello Giulietti , core-libs-dev@openjdk.java.net Subject: Re: RFR: 8279986: methods Math::asXExact for safely checked primitive casts This work is quite timely as we are now paving the way for primitive type patterns over in Project Amber, and also has a nontrivial connection with Valhalla. If you'll pardon a brief digression... Instanceof and casting work together in a familiar way: before you cast, you first ask instanceof -- but this is restricted currently to reference types. But the pattern is obvious: instanceof is the precondition check for casting, which asks: "If I made this cast, would I like the answer." There are currently two reasons to not like the answer: a CCE, or the operand is null (because, even though the cast would succeed, if you tried to use it as a member of that type, you wouldn't like the answer then.) If we wanted to extend `instanceof` to primitive types, we are asking the same question: if I were to cast to this type, would I like the answer. And casts involving primitives give us two more reasons to not like the answer: an NPE (due to unboxing), or loss of precision. Which means that we have to specify in JLS 5.1 what cast with loss of precision means. At the very least, we will want to align this work with that; the asXExact should be able to say "throws if the cast would lose precision", where "lose precision" is precisely defined by the JLS. Separately, Project Valhalla will let us define new primitive-like types, such as HalfFloat and SuperLong. Conversions between primitives are currently specified in a complex table in JLS 5.1. But surely we will want to support primitive widening conversions between HalfFloat and float (somehow; how we do this is a separate discussion.) Which brings us back to pattern matching; narrowing casts are inherently partial, and declared patterns bring partiality into the "return type", and are the natural way (when we have it) to express things like "cast, but fail if you can't do so safely". This is preferable to throwing (which currently is the our choice.) So it might be a little unfortunate to introduce throwing toXExactly now and then have to introduce separate patterns which signal precision loss by match failure. (Though that's not the end of the world if there is some duplication.) What this says is that the current proposal of toXExact is not the primitive, because we probably wouldn't want to implement a pattern in terms of the throwing version. Converting from float/double to integral types is particularly tricky with -0.0. Both answers kind of suck. (This is a familiar situation, and these can be very difficult to resolve, as for each position, *someone* has decided the other position is untenable.) I understand the rationale behind Michael H's "but its not exact", but let's not pretend one answer is good and the other sucks -- they both suck, and therefore the decision can be made on other factors. So I have a few new wrinkles to add to the story: - We should wait until we have candidate JLS text for "cast conversion without loss of precision", and ensure the two are consistent, before pushing; - I not quite comfortable with settling the -0.0 issue just yet, there are some other explorations to complete first; - We should be prepared for the fact that we will, sometime soon, have to implement this whole set again as patterns that do not throw. On 5/5/2022 6:1
Re: RFR: 8279986: methods Math::asXExact for safely checked primitive casts [v6]
> Add a family of "safe" cast methods. Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: 8279986: methods Math::asXExact for safely checked primitive casts - Changes: - all: https://git.openjdk.java.net/jdk/pull/8548/files - new: https://git.openjdk.java.net/jdk/pull/8548/files/5fb1fed4..4cf9a8cf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=8548=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8548=04-05 Stats: 6 lines in 2 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/8548.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8548/head:pull/8548 PR: https://git.openjdk.java.net/jdk/pull/8548
Re: RFR: 8279986: methods Math::asXExact for safely checked primitive casts
This work is quite timely as we are now paving the way for primitive type patterns over in Project Amber, and also has a nontrivial connection with Valhalla. If you'll pardon a brief digression... Instanceof and casting work together in a familiar way: before you cast, you first ask instanceof -- but this is restricted currently to reference types. But the pattern is obvious: instanceof is the precondition check for casting, which asks: "If I made this cast, would I like the answer." There are currently two reasons to not like the answer: a CCE, or the operand is null (because, even though the cast would succeed, if you tried to use it as a member of that type, you wouldn't like the answer then.) If we wanted to extend `instanceof` to primitive types, we are asking the same question: if I were to cast to this type, would I like the answer. And casts involving primitives give us two more reasons to not like the answer: an NPE (due to unboxing), or loss of precision. Which means that we have to specify in JLS 5.1 what cast with loss of precision means. At the very least, we will want to align this work with that; the asXExact should be able to say "throws if the cast would lose precision", where "lose precision" is precisely defined by the JLS. Separately, Project Valhalla will let us define new primitive-like types, such as HalfFloat and SuperLong. Conversions between primitives are currently specified in a complex table in JLS 5.1. But surely we will want to support primitive widening conversions between HalfFloat and float (somehow; how we do this is a separate discussion.) Which brings us back to pattern matching; narrowing casts are inherently partial, and declared patterns bring partiality into the "return type", and are the natural way (when we have it) to express things like "cast, but fail if you can't do so safely". This is preferable to throwing (which currently is the our choice.) So it might be a little unfortunate to introduce throwing toXExactly now and then have to introduce separate patterns which signal precision loss by match failure. (Though that's not the end of the world if there is some duplication.) What this says is that the current proposal of toXExact is not the primitive, because we probably wouldn't want to implement a pattern in terms of the throwing version. Converting from float/double to integral types is particularly tricky with -0.0. Both answers kind of suck. (This is a familiar situation, and these can be very difficult to resolve, as for each position, *someone* has decided the other position is untenable.) I understand the rationale behind Michael H's "but its not exact", but let's not pretend one answer is good and the other sucks -- they both suck, and therefore the decision can be made on other factors. So I have a few new wrinkles to add to the story: - We should wait until we have candidate JLS text for "cast conversion without loss of precision", and ensure the two are consistent, before pushing; - I not quite comfortable with settling the -0.0 issue just yet, there are some other explorations to complete first; - We should be prepared for the fact that we will, sometime soon, have to implement this whole set again as patterns that do not throw. On 5/5/2022 6:18 AM, Raffaello Giulietti wrote: Add a family of "safe" cast methods. - Commit messages: - 8279986: methods Math::asXExact for safely checked primitive casts - 8279986: methods Math::asXExact for safely checked primitive casts - 8279986: methods Math::asXExact for safely checked primitive casts Changes:https://git.openjdk.java.net/jdk/pull/8548/files Webrev:https://webrevs.openjdk.java.net/?repo=jdk=8548=00 Issue:https://bugs.openjdk.java.net/browse/JDK-8279986 Stats: 615 lines in 2 files changed: 609 ins; 0 del; 6 mod Patch:https://git.openjdk.java.net/jdk/pull/8548.diff Fetch: git fetchhttps://git.openjdk.java.net/jdk pull/8548/head:pull/8548 PR:https://git.openjdk.java.net/jdk/pull/8548
Re: RFR: 8279986: methods Math::asXExact for safely checked primitive casts [v5]
> Add a family of "safe" cast methods. Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: 8279986: methods Math::asXExact for safely checked primitive casts - Changes: - all: https://git.openjdk.java.net/jdk/pull/8548/files - new: https://git.openjdk.java.net/jdk/pull/8548/files/f629f5b3..5fb1fed4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=8548=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8548=03-04 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8548.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8548/head:pull/8548 PR: https://git.openjdk.java.net/jdk/pull/8548
Re: RFR: 8279986: methods Math::asXExact for safely checked primitive casts [v4]
On Mon, 23 May 2022 18:37:26 GMT, Raffaello Giulietti wrote: >> Add a family of "safe" cast methods. > > Raffaello Giulietti has updated the pull request incrementally with one > additional commit since the last revision: > > 8279986: methods Math::asXExact for safely checked primitive casts Marked as reviewed by kristyle...@github.com (no known OpenJDK username). - PR: https://git.openjdk.java.net/jdk/pull/8548
Re: RFR: 8279986: methods Math::asXExact for safely checked primitive casts [v4]
> Add a family of "safe" cast methods. Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: 8279986: methods Math::asXExact for safely checked primitive casts - Changes: - all: https://git.openjdk.java.net/jdk/pull/8548/files - new: https://git.openjdk.java.net/jdk/pull/8548/files/5f0ff527..f629f5b3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=8548=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8548=02-03 Stats: 201 lines in 1 file changed: 196 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/8548.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8548/head:pull/8548 PR: https://git.openjdk.java.net/jdk/pull/8548
Re: RFR: 8279986: methods Math::asXExact for safely checked primitive casts [v3]
On Tue, 10 May 2022 13:47:35 GMT, Raffaello Giulietti wrote: >> Add a family of "safe" cast methods. > > Raffaello Giulietti has updated the pull request incrementally with one > additional commit since the last revision: > > 8279986: methods Math::asXExact for safely checked primitive casts As a reminder, once the spec is finalized, versions of the methods and spec need to be added to StrictMath too. - PR: https://git.openjdk.java.net/jdk/pull/8548
Re: RFR: 8279986: methods Math::asXExact for safely checked primitive casts [v3]
> Add a family of "safe" cast methods. Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: 8279986: methods Math::asXExact for safely checked primitive casts - Changes: - all: https://git.openjdk.java.net/jdk/pull/8548/files - new: https://git.openjdk.java.net/jdk/pull/8548/files/7be0f9de..5f0ff527 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=8548=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8548=01-02 Stats: 35 lines in 2 files changed: 0 ins; 0 del; 35 mod Patch: https://git.openjdk.java.net/jdk/pull/8548.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8548/head:pull/8548 PR: https://git.openjdk.java.net/jdk/pull/8548
Re: RFR: 8279986: methods Math::asXExact for safely checked primitive casts [v2]
On Tue, 10 May 2022 04:42:19 GMT, Joe Darcy wrote:
>> Raffaello Giulietti has updated the pull request with a new target base due
>> to a merge or a rebase. The incremental webrev excludes the unrelated
>> changes brought in by the merge/rebase. The pull request contains four
>> additional commits since the last revision:
>>
>> - 8279986: methods Math::asXExact for safely checked primitive casts
>>
>>Merge branch 'master' into JDK-8279986
>> - 8279986: methods Math::asXExact for safely checked primitive casts
>>
>>Merge branch 'master' into JDK-8279986
>> - 8279986: methods Math::asXExact for safely checked primitive casts
>> - 8279986: methods Math::asXExact for safely checked primitive casts
>
> src/java.base/share/classes/java/lang/Math.java line 1578:
>
>> 1576: */
>> 1577: @ForceInline
>> 1578: public static long toUnsignedIntExact(long value) {
>
> Existing methods like Integer.parseUnsignedInt interpret the negative int
> values as positive values larger than MAX_INT. So if an int is not going to
> be returned here, I suggest a name like "toUnsignedIntRangeExact".
Returning a `long` is probably less error prone.
When the result is to be used in an `int` context, one simply has to add a
`(int)` cast, as mandated by language, compiler and IDE.
On the other hand, if this method were to return an `int`, when using the
result in a `long` context one has to remember masking it with `0x_L`.
AFAIK, there's no compiler or IDE support for this.
The name `toUnsignedIntRangeExact` is certainly better.
-
PR: https://git.openjdk.java.net/jdk/pull/8548
Re: RFR: 8279986: methods Math::asXExact for safely checked primitive casts [v2]
On Mon, 9 May 2022 09:26:58 GMT, Raffaello Giulietti
wrote:
>> Add a family of "safe" cast methods.
>
> Raffaello Giulietti has updated the pull request with a new target base due
> to a merge or a rebase. The incremental webrev excludes the unrelated changes
> brought in by the merge/rebase. The pull request contains four additional
> commits since the last revision:
>
> - 8279986: methods Math::asXExact for safely checked primitive casts
>
>Merge branch 'master' into JDK-8279986
> - 8279986: methods Math::asXExact for safely checked primitive casts
>
>Merge branch 'master' into JDK-8279986
> - 8279986: methods Math::asXExact for safely checked primitive casts
> - 8279986: methods Math::asXExact for safely checked primitive casts
src/java.base/share/classes/java/lang/Math.java line 1367:
> 1365: * Returns the value of the {@code double} argument,
> 1366: * throwing an exception if the conversion is inexact.
> 1367: * The method returns iff the argument and the result
Style suggestion: given the audience of the javadoc, rather than "iff" write
out "if and only if" or other full word construct.
src/java.base/share/classes/java/lang/Math.java line 1578:
> 1576: */
> 1577: @ForceInline
> 1578: public static long toUnsignedIntExact(long value) {
Existing methods like Integer.parseUnsignedInt interpret the negative int
values as positive values larger than MAX_INT. So if an int is not going to be
returned here, I suggest a name like "toUnsignedIntRangeExact".
-
PR: https://git.openjdk.java.net/jdk/pull/8548
Re: RFR: 8279986: methods Math::asXExact for safely checked primitive casts [v2]
On Mon, 9 May 2022 09:26:58 GMT, Raffaello Giulietti wrote: >> Add a family of "safe" cast methods. > > Raffaello Giulietti has updated the pull request with a new target base due > to a merge or a rebase. The incremental webrev excludes the unrelated changes > brought in by the merge/rebase. The pull request contains four additional > commits since the last revision: > > - 8279986: methods Math::asXExact for safely checked primitive casts > >Merge branch 'master' into JDK-8279986 > - 8279986: methods Math::asXExact for safely checked primitive casts > >Merge branch 'master' into JDK-8279986 > - 8279986: methods Math::asXExact for safely checked primitive casts > - 8279986: methods Math::asXExact for safely checked primitive casts Post Loom merge - PR: https://git.openjdk.java.net/jdk/pull/8548
Re: RFR: 8279986: methods Math::asXExact for safely checked primitive casts [v2]
> Add a family of "safe" cast methods. Raffaello Giulietti has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - 8279986: methods Math::asXExact for safely checked primitive casts Merge branch 'master' into JDK-8279986 - 8279986: methods Math::asXExact for safely checked primitive casts Merge branch 'master' into JDK-8279986 - 8279986: methods Math::asXExact for safely checked primitive casts - 8279986: methods Math::asXExact for safely checked primitive casts - Changes: - all: https://git.openjdk.java.net/jdk/pull/8548/files - new: https://git.openjdk.java.net/jdk/pull/8548/files/4d0924c5..7be0f9de Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=8548=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8548=00-01 Stats: 103190 lines in 1255 files changed: 93727 ins; 4219 del; 5244 mod Patch: https://git.openjdk.java.net/jdk/pull/8548.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8548/head:pull/8548 PR: https://git.openjdk.java.net/jdk/pull/8548
Re: RFR: 8279986: methods Math::asXExact for safely checked primitive casts
On Thu, 5 May 2022 15:07:32 GMT, Michael Hixson wrote: > Rationale: It loses information. It truncates the sign, so the value can't be > round-tripped. I think it would be the only lossy transformation permitted by > the to*Exact methods? Right. - PR: https://git.openjdk.java.net/jdk/pull/8548
Re: RFR: 8279986: methods Math::asXExact for safely checked primitive casts
On Thu, 5 May 2022 14:32:36 GMT, Raffaello Giulietti wrote: > So, what is the use case or the rationale for throwing on -0.0? Rationale: It loses information. It truncates the sign, so the value can't be round-tripped. I think it would be the only lossy transformation permitted by the `to*Exact` methods? Use case: None. I haven't worked on a program where -0.0 -> OL -> +0.0 would have caused me a problem. - PR: https://git.openjdk.java.net/jdk/pull/8548
Re: RFR: 8279986: methods Math::asXExact for safely checked primitive casts
On Thu, 5 May 2022 10:11:05 GMT, Raffaello Giulietti wrote: > Add a family of "safe" cast methods. The JLS specifies that the cast (officially, "narrowing primitive conversion") (long)-0.0 returns 0L. As these methods are meant to be safer casts, I think we should follow the JLS as closely as possible. Besides, throwing on -0.0 would make the implementation slightly more convoluted. We want C2 to emit efficient inlineable code. So, what is the use case or the rationale for throwing on -0.0? - PR: https://git.openjdk.java.net/jdk/pull/8548
Re: RFR: 8279986: methods Math::asXExact for safely checked primitive casts
On Thu, 5 May 2022 10:11:05 GMT, Raffaello Giulietti wrote: > Add a family of "safe" cast methods. This PR also solves [JDK-8154433](https://bugs.openjdk.java.net/browse/JDK-8154433), though you went the other way on -0.0. - PR: https://git.openjdk.java.net/jdk/pull/8548
Re: RFR: 8279986: methods Math::asXExact for safely checked primitive casts
On Thu, 5 May 2022 10:11:05 GMT, Raffaello Giulietti wrote: > Add a family of "safe" cast methods. For an in-depth rationale, please refer to the issue (Enhancement). Note that the method names are, in fact, of the to*Exact rather than of the as*Exact form - PR: https://git.openjdk.java.net/jdk/pull/8548
