RFR: 8377895: Create sizeof_auto to reduce narrowing conversions [v2]

[Leo Korinth]

On Wed, 18 Feb 2026 09:08:11 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>>> > it is checked at runtime, not compile time.
>>> > it is checked only on debug builds
>>> 
>>> Both points are true, but for the specific goal here—reducing narrowing conversion warnings—I don’t think either of those limitations are material. The compiler will still complain at any remaining implicit narrowing sites, so we’re not relying on runtime checking to catch them.
>>> 
>>> > you need to use it, it will make the code harder to read, it is easier to use sizeof_auto
>>> 
>>> On the readability point, I think that’s somewhat subjective. Introducing a new `sizeof`-like API changes the type semantics of `sizeof`, which feels like a broader conceptual shift. Since we already have `checked_cast` to make narrowing explicit, using it seems more localized and avoids adding another abstraction to the codebase.
>>> 
>>> Just my 2c.
>> 
>> I see every cast as a potential bug. That is why I want to have warnings enabled for implicit narrowing conversions, because they hide bugs. If I can have an assignment or expression without a cast, that makes it so much easier to read, because I do not need to consider if I am loosing information (when erroring on implicit narrowing conversions). Using `sizeof_auto` will create safe promotions instead of unsafe narrowing conversions needing a cast.
>
>> I see every cast as a potential bug. That is why I want to have warnings enabled for implicit narrowing conversions, because they hide bugs...
> 
> I agree that casts are often a smell, and enabling warnings for implicit narrowing conversions is absolutely the right goal.
> 
> I also see that `sizeof_auto` removes narrowing at the source for `sizeof`, which is nice. However, `sizeof` is only one source of narrowing conversions. If we use `sizeof_auto` for this specific case but still rely on `checked_cast` elsewhere, we end up with two different mechanisms addressing the same problem. That might introduce more conceptual overhead than simply using one consistent approach.
> 
> There’s also the broader consistency question: once we introduce `sizeof_auto`, developers need to decide between `sizeof` and `sizeof_auto`. Is this intended to replace most `sizeof` usages in size computations, or only specific ones? Without a clear rule, we may end up with mixed semantics in the codebase.
> 
> Since we already have `checked_cast` for explicit narrowing, keeping a single, consistent mechanism feels simpler to me.

I used a modified version of @albertnetymk idea, with the help of @xmas92

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29716#issuecomment-3951819593