`PrivateMethods`' items aren't private, they are accessible via `MaskElement`

[obi1kenobi]

A surprising new SemVer breakage case was discovered earlier this week, affecting sealed traits' associated items (consts, types, functions with or without receivers — everything) being accessible to subtraits. This is non-obvious and usually isn't intended by the authors of such code, which can lead to accidental breakage.

portable-simd has such an at-risk pattern here

mod private_methods {
    pub impl(super) trait PrivateMethods {
        fn valid<const N: usize>(values: Simd<Self, N>) -> bool
        where
            Self: SimdElement;

        fn eq(self, other: Self) -> bool;

        fn to_usize(self) -> usize;
        fn max_unsigned() -> u64;

        type Unsigned: SimdElement;

        const TRUE: Self;

        const FALSE: Self;
    }
}

Despite the name PrivateMethods, all of those items and methods are accessible downstream (including in downstream crates) via any pub subtrait of PrivateMethods, such as the adjacent MaskElement:

pub impl(self) unsafe trait MaskElement:
    SimdElement<Mask = Self> + SimdCast + PrivateMethods {}

Stabilizing MaskElement could lead to accidentally stabilizing all those PrivateMethods items too, which seems undesirable.

This is a sibling issue of rust-lang/rust#158654 which flags an analogous concern in the Rust standard library itself.

Hat tip to @jhpratt for looping me in to look at the SemVer breakage and suggesting that we scan portable-simd for this pattern. I used AI tools for the scan, but wrote this issue fully by hand otherwise.

[bjorn3]

Stabilizing MaskElement would de facto stabilize all those PrivateMethods items too, which seems undesirable.

I don't think that is the case. To mark core::simd::MaskElement as stable, core::simd would have to be marked as stable too, which will then require all items in core::simd that are not in unstable modules to be explicitly marked as either stable or unstable as they would no longer inherit the unstable attribute from core::simd. At that point either PrivateMethods directly or private_methods would almost certainly be marked as explicitly unstable and thus not be callable from stable.

That said the fact that PrivateMethods can be called even on nightly seems unintentional and something that should be fixed either way.

[obi1kenobi]

Thanks, edited slightly for clarity.

[jhpratt]

That said the fact that PrivateMethods can be called even on nightly seems unintentional and something that should be fixed either way.

This was my mistake, as I believed that to be accurate. It obviously wasn't caught in review. It was previously called Sealed.

[workingjubilee]

Thanks for highlighting this! It's unclear what we want to do here but do indeed want to at least be aware of what the consequences of what we are stabilizing as we try to prepare for that.