-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
#fmt should allow any width int, float, etc to be used #1653
Comments
It would be nice if this worked. I wonder if one way would be to simply promote the argument to u64 or i64 as appropriate?
|
(Such promotion is, after all, how printf works for types smaller than int) |
Yeah, we could totally do that. I never really considered implementing it like that because it's a silly little price to pay, but it's very easy, and if there's any real performance impact it's probably not important. |
In general it'd be nice to have type information in the extensions. |
It would make error messages about incorrect types slightly more opaque (they would be about bad casts to i64, etc.) and would allow for some things that are unexpected, #fmt("%b", 1000) - anything that's castable. |
The point about error msgs is well-taken. As for "%b" (that's boolean, right?), I don't think you need to use |
You're right that %b (bool) wouldn't be affected. Basically, I think doing the cast is ok, but if we really wanted to limit the casts to just the obvious stuff, we could add an iface to do the conversion:
Then #fmt could expand every int argument to |
I considered suggesting an iface, but I rejected it because it wouldn't be in scope. I didn't think of using a block to limit the scope like that, clever. |
Thinking about this now, I think that if we were to use an iface, we would probably want to have the core imports bring the impls into scope for the built-in types. This would allow people to override them on a file-by-file basis, as well as allowing user-defined types to work with %d, %s, etc. If the aim is not to allow user-defined types and customizable formatting, then I would advocate just casting to |
I'd love to see this happen. I'm getting tired of throwing in casts every time I want to print the hex value of a |
It seems that currently |
Update 'or_fun_call' to ignore calls to len Resolves rust-lang#1653 changelog: Update `or_fun_call`: Allow calls to `len` for Slice, Array & Vec.
It would be nice if "%d" would work for any signed integer type, etc. Doing this would require giving extensions access to type information.
The text was updated successfully, but these errors were encountered: