Skip to content

Tracking Issue for fn unsigned_abs #74913

Closed

Description

@carbotaniuman

This is a tracking issue for fn unsigned_abs on signed integral types.
The feature gate for the issue is #![feature(unsigned_abs)].

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also uses as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

Steps

Implementation history

First implemented in #74759

Activity

  1. added
    C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFC
    on Jul 29, 2020
  2. added
    B-unstableBlocker: Implemented in the nightly compiler and unstable.
    T-libs-api[DEPRECATED; DO NOT USE]
    on Jul 29, 2020
  3. added
    Libs-SmallLibs issues that are considered "small" or self-contained
    I-libs-radarLibs issues that are tracked on the team's radar.
    on Jul 30, 2020
  4. jhpratt commented on Nov 5, 2020

    @jhpratt
    Member

    Are there any outstanding issues with this feature gate? It has a trivial implementation that is unquestionably correct, and it seemed quite clear in the RFC that it was desired.

  5. Kixunil commented on Nov 5, 2020

    @Kixunil
    Contributor

    One significant issue I see is currently the implementation for isize returns u64 instead of usize.

    Documentation of the function
    Playground proof that the implementation matches the documentation

    Edit: I found the reason. The macro int_impl is called with u64 instead of usize as $UnsignedT. This was not a problem so far because $UnsignedT didn't appear in any function signature until now. So changing the call site for all pointer sizes should be enough.

  6. jhpratt commented on Nov 5, 2020

    @jhpratt
    Member

    Hmm…the behavior is different for different widths (16, 32, or 64). However, usize and u16/32/64 are not the same type. I'll make a modification locally and open a PR shortly.

  7. Kixunil commented on Nov 6, 2020

    @Kixunil
    Contributor

    Yes, exactly. Good job with the PR!

  8. added 4 commits that reference this issue on Nov 7, 2020
  9. AngelicosPhosphoros commented on Dec 12, 2020

    @AngelicosPhosphoros
    Contributor

    Why unsigned_abs of isize returns u64 instead of usize?
    IMHO, it is not valid.
    https://doc.rust-lang.org/std/primitive.isize.html#method.unsigned_abs

    @carbotaniuman @jhpratt

  10. CryZe commented on Dec 12, 2020

    @CryZe
    Contributor

    This is fixed on nightly (that you need anyway to use this for now)

  11. AngelicosPhosphoros commented on Dec 12, 2020

    @AngelicosPhosphoros
    Contributor

    Nice, thank you!

  12. added a commit that references this issue on Jan 30, 2021
    91ea1cb
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

    B-unstableBlocker: Implemented in the nightly compiler and unstable.C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCI-libs-radarLibs issues that are tracked on the team's radar.Libs-SmallLibs issues that are considered "small" or self-containedT-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