Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Decide whether to keep pointer sized integers as the default #11831

Closed
brson opened this issue Jan 27, 2014 · 7 comments
Closed

Decide whether to keep pointer sized integers as the default #11831

brson opened this issue Jan 27, 2014 · 7 comments
Labels
A-type-system Area: Type system
Milestone

Comments

@brson
Copy link
Contributor

brson commented Jan 27, 2014

I know there are other issues related to this, but I want to make a firm decision one way or the other on whether we want to commit to int and uint being pointer sized. Whatever the decision add it to the design FAQ (#4047). Nominating.

@huonw
Copy link
Member

huonw commented Jan 27, 2014

I don't see how this is different to #6023 (removing the default to int) and #9940 (changing the int name).

Also, if we keep a type called int, and it's non-pointer-sized, then it's either fixed size (i.e. it's i32 or something, in which case there is no point in keeping it) or it's arbitrary precision (but then I'd argue that it should be called Int).

@brson
Copy link
Contributor Author

brson commented Jan 27, 2014

They are both related, and motivated by the notion that pointer sized ints are wrong: #6023 just suggests removing inference and #9940 is a proposal to rename int and uint. There other potential solutions if int and uint should not be pointer sized.

@pnkfelix
Copy link
Member

Accepted for 1.0, P-backcompat-lang

@nikomatsakis
Copy link
Contributor

A summary of what I see as the related issues in this discussion:

  • what does uint mean, if anything
    • nothing, just use uintptr
    • always use 32 bit
    • use bigint
  • do we want a default fallback when we can't infer a specific integer type
  • what types do we accept for indexing and shifting (currently we're kind of permissive)

@brson
Copy link
Contributor Author

brson commented Apr 15, 2014

Nominating for closing, along with #6023 and #9940. Unless we do this right now, I don't see it happening.

@thestinger
Copy link
Contributor

I think it's fine to have int and uint as pointer-size integers, and the bug I opened about it was not much more than a bikeshed. I do think it's really important to remove the fallback to int to prevent bugs caused by relying on type inference.

@pnkfelix
Copy link
Member

closing.

bors pushed a commit to rust-lang-ci/rust that referenced this issue Dec 1, 2023
clippy::suboptimal_flops used to not check if the second parameter to f32/f64.mul_add() was float. Since the method is
only defined to take `Self` as paremters, the suggestion was wrong.

Fixes rust-lang#11831
bors added a commit to rust-lang-ci/rust that referenced this issue Dec 1, 2023
Don't suggest `a.mul_add(b, c)` if parameters are not float

clippy::suboptimal_flops used to not check if the second parameter to f32/f64.mul_add() was float. Since the method is only defined to take `Self` as parameters, the suggestion was wrong.

Fixes rust-lang#11831

changelog: [`suboptimal_float`]: Don't suggest `a.mul_add(b, c)` if parameters are not f32/f64
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-type-system Area: Type system
Projects
None yet
Development

No branches or pull requests

5 participants