-
Notifications
You must be signed in to change notification settings - Fork 13k
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
integer literals could be more generic #4169
Comments
Why is this backwards incompatible? |
@pcwalton: it shouldn't be afaik, it won't result in any backwards incompatible changes. This can be done way post 1.0 without any harmful effects - ghc added overloading to strings very recently. I removed the tag. |
Visiting for triage; carry on. |
visiting for triage, email from 2013-08-26. Deliberately not nominating for maturity milestone (I don't want to bucket this in far-future, even though I think that's where it would belong as a wishlist item). |
This needs an RFC, and seems related to the FromLiteral RFC which got postponed. @thestinger Should this be moved to the rfcs repository? |
Closing in favour of rust-lang/rfcs#265. |
Right now, integer literals will only be implicitly converted to built-in integer types. This makes it quite verbose to use big integers, even when the initial values can be held within an int. The implicit conversion could be extended to any type implementing the Num trait, since it includes
from_int
(maybe using an attribute to make the inference optional).This still doesn't make it as generic as the Num literals in Haskell, which are able to represent a value larger than what an Int can hold - but doing that could wait until Rust has big integer support in the standard library (or built-in, at least for literals).
This also applies to literals like
0.5
, which could be used for arbitrary precision floating point types that aren't necessarily in base 2.The text was updated successfully, but these errors were encountered: