Skip to content

Tracking Issue for NonZero_c_* integers #82363

Closed
#120295
Closed
Tracking Issue for NonZero_c_* integers#82363
#120295
Labels
A-FFIArea: Foreign function interface (FFI)C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCT-libs-api[DEPRECATED; DO NOT USE]

Description

@KodrAus
KodrAus
opened on Feb 21, 2021

Feature gate: #![feature(raw_os_nonzero)]

This is a tracking issue for non-zero variants of c_int type aliases.

Public API

pub type NonZero_c_char = NonZero?8;
pub type NonZero_c_schar = NonZeroI8;
pub type NonZero_c_uchar = NonZeroU8;
pub type NonZero_c_short = NonZeroI16;
pub type NonZero_c_ushort = NonZeroU16;
pub type NonZero_c_int = NonZeroI32;
pub type NonZero_c_uint = NonZeroU32;
#[cfg(any(target_pointer_width = "32", windows))]
pub type NonZero_c_long = NonZeroI32;
#[cfg(any(target_pointer_width = "32", windows))]
pub type NonZero_c_ulong = NonZeroU32;
#[cfg(all(target_pointer_width = "64", not(windows)))]
pub type NonZero_c_long = NonZeroI64;
#[cfg(all(target_pointer_width = "64", not(windows)))]
pub type NonZero_c_ulong = NonZeroU64;
pub type NonZero_c_longlong = NonZeroI64;
pub type NonZero_c_ulonglong = NonZeroU64;

Steps / History

Unresolved Questions

  • Naming.....

Activity

  1. KodrAus
    added
    T-libs-api[DEPRECATED; DO NOT USE]
    C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFC
    on Feb 21, 2021

  2. tesuji commented on Feb 21, 2021

    @tesuji
    tesuji
    on Feb 21, 2021 · Hidden as resolved
  3. jonas-schievink
    added
    A-FFIArea: Foreign function interface (FFI)
    on Feb 21, 2021

  4. joshtriplett commented on Aug 25, 2021

    @joshtriplett
    joshtriplett
    on Aug 25, 2021
    Member

    FCP for stabilization:

    @rfcbot merge

  5. rfcbot commented on Aug 25, 2021

    @rfcbot
    rfcbot
    on Aug 25, 2021

    Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:

    Concerns:

    Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

    See this document for info about what commands tagged team members can give me.

  6. rfcbot
    added
    proposed-final-comment-periodProposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off.
    disposition-mergeThis issue / PR is in PFCP or FCP with a disposition to merge it.
    on Aug 25, 2021

  7. dtolnay commented on Aug 26, 2021

    @dtolnay
    dtolnay
    on Aug 26, 2021
    Member

    NonZero_c_ulonglong

    I can't say that I am thrilled about Pascal_snake_concatwords-case. Can we reconsider doing a generic type alias instead?

    // core::num

/// NonZero<i8> = NonZeroI8
/// NonZero<i16> = NonZeroI16
/// etc
pub type NonZero<N> = <N as private::Primitive>::NonZero;

    This would automatically be usable as NonZero<c_char> = NonZeroI8/NonZeroU8 (based on platform).

    Note we don't need to make any underlying trait publicly accessible. This is not for writing generic code over all different nonzero types. It is just for saner spelling of the type names.

  8. joshtriplett commented on Aug 26, 2021

    @joshtriplett
    joshtriplett
    on Aug 26, 2021
    Member

    If that kind of generic is possible, I'm all for it. Is it?

  9. Amanieu commented on Aug 26, 2021

    @Amanieu
    Amanieu
    on Aug 26, 2021
    Member

    I also think that these names are very ugly and would vastly prefer a generic NonZero type based on a sealed trait.

    @rfcbot concern generic NonZero

  10. kennytm commented on Sep 17, 2021

    @kennytm
    kennytm
    on Sep 17, 2021
    Member

    IMO introducing AtomicT/NonZeroT replacing Atomic<T>/NonZero<T> are the gravest API mistake Rust has ever made so +1 to introducing NonZero<T> again.

    The 12 NonZeroT types are introduced in rust-lang/rfcs#2307 was to sidestep the question what should happen to NonZero<CustomType>, taking the precedent of AtomicT (but disregarding Wrapping<T>).

    One problem of the current API is that it is unclear what happens or what should happen to NonZero<T> or Option<NonZero<T>> when T is some type other than a raw pointer or a primitive integer. In particular, crates outside of std can implement Zeroable for their arbitrary types since it is a public trait.

    To avoid this question entirely, this RFC proposes replacing the generic type and trait with twelve concrete types in std::num, one for each primitive integer type. This is similar to the existing atomic integer types like std::sync::atomic::AtomicU32.

    The Motivation no longer applies since, as demonstrated in in #88990, we can make the bounding trait IntegerPrimitive (previously Zeroable) a private/sealed trait. During FCP SimonSapin did mention (in rust-lang/rfcs#2307 (comment) and rust-lang/rfcs#2307 (comment)) why this route was not considered, mainly because of type checker bugs and personal taste. It was agreed in rust-lang/rfcs#2307 (comment) that the question won't block the FCP-merge. Yet the question of generics was not checkboxed in #49137 before stabilization of NonZeroT.

    Now that this issue shows that generics is greatly favored, I think we should better do it properly by turning NonZero<T> back to a struct, and NonZeroT direct type aliases, rather than the current implementation that NonZeroT are concrete types and NonZero<T> being an alias going jumping through associated types.

    // no reexport
pub trait IntegerPrimitive: Sized + Copy + Ord + Hash + Default + BitOr<Output=Self> + Debug + Display + Binary + Octal + LowerHex + UpperHex {}

#[unstable(...)] 
#[derive(Copy, Clone, Eq, PartialEq, Ord, PartialOrd, Hash)]
#[repr(transparent)]
#[rustc_layout_scalar_valid_range_start(1)]
#[rustc_nonnull_optimization_guaranteed]
pub struct NonZero<T: IntegerPrimitive>(T);

impl<T: IntegerPrimitive> NonZero<T> {
    #[stable(..)]
    pub const unsafe fn new_unchecked(n: T) -> Self { unsafe { Self(n) } }
    pub const fn new(n: T) -> Option<Self> { (n != T::default()).then(|| unsafe { Self(n) }) }
    pub const fn get(self) -> T { self.0 }
}

#[stable(..)]
impl<T: IntegerPrimitive> BitOr for NonZero<T> {}

//... etc ...

#[stable(..)]
pub type NonZeroU8 = NonZero<u8>;
pub type NonZeroU16 = NonZero<u16>;
...
pub type NonZeroI128 = NonZero<i128>;
pub type NonZeroIsize = NonZero<isize>;

    the inherent functions leading_zeros, trailing_zeros, {checked,saturating,unchecked}_{add,mul,pow}, checked_next_power_of_two, abs, {checked,overflowing,saturating,wrapping,unsigned}_abs, is_power_of_two still require per-instance impl by macro.

  11. joshtriplett commented on Oct 5, 2021

    @joshtriplett
    joshtriplett
    on Oct 5, 2021
    Member

    I'd be happy to review a pull request adding a generic NonZero based on a sealed trait.

  12. joshtriplett commented on Oct 5, 2021

    @joshtriplett
    joshtriplett
    on Oct 5, 2021
    Member

    Cancelling in favor of generic NonZero.
    @rfcbot cancel

  13. rfcbot commented on Oct 5, 2021

    @rfcbot
    rfcbot
    on Oct 5, 2021

    @joshtriplett proposal cancelled.

  14. rfcbot
    removed
    proposed-final-comment-periodProposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off.
    disposition-mergeThis issue / PR is in PFCP or FCP with a disposition to merge it.
    on Oct 5, 2021

  15. CAD97 commented on Jul 17, 2022

    @CAD97
    CAD97
    on Jul 17, 2022
    Contributor

    Just as a note: std is missing a reëxport of these names from core.

  16. reitermarkus commented on Aug 11, 2022

    @reitermarkus
    reitermarkus
    on Aug 11, 2022
    Contributor

    I had a go at implementing a generic NonZero type here #100428.

  17. briansmith commented on Nov 27, 2023

    @briansmith
    briansmith
    on Nov 27, 2023
    Contributor

    NonZero_c_size_t and NonZero_c_ptrdiff_t are missing from core::ffi.

  18. matthiaskrgr
    added a commit that references this issue on Jan 19, 2024

    Rollup merge of rust-lang#118665 - dtolnay:signedness, r=Nilstrieb

    122b3f9
  19. rust-timer
    added a commit that references this issue on Jan 19, 2024

    Unrolled build for rust-lang#118665

    9bbd58c
  20. github-actions
    added a commit that references this issue on Jan 21, 2024

    Rollup merge of #118665 - dtolnay:signedness, r=Nilstrieb

    f04bf87
  21. GuillaumeGomez
    added a commit that references this issue on Jan 30, 2024

    Rollup merge of rust-lang#120295 - reitermarkus:remove-ffi-nonzero, r…

    4f4ceef
  22. bors
    closed this as completedin 4f4ceefon Jan 30, 2024
  23. rust-timer
    added a commit that references this issue on Jan 30, 2024

    Unrolled build for rust-lang#120295

    615a32b

  24. dtolnay commented on Jan 30, 2024

    @dtolnay
    dtolnay
    on Jan 30, 2024
    Member

    Superseded by #120257.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-FFIArea: Foreign function interface (FFI)C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCT-libs-api[DEPRECATED; DO NOT USE]

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions