-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
Macro expand step for (s)printf #9243
Conversation
Does this also allow the use of multiline (triple-quoted) strings? |
This seems like a very heavy-handed approach just to allow reusing format strings. Needing to define the format string as a macro is not great either. I think a better approach would be to allow a symbol as the format string, and call Of course you can also do
right now. However that is a bit awkward, and it would be better to have syntax to force evaluation of macro arguments before expansion. The larger point is, this should not need to be specific to printf, and defining constants using macros is not ideal. |
Wouldn't this also allow
for some global constant fmt? |
I think we just need a better overall approach to printf. The current macro is kind of awkward. |
Wouldn't calling |
Yes, that's a problem. Of course I've always said not to call @StefanKarpinski might be right here. For example we could have |
For what it's worth, I was planning on revisiting this after strings are redone as part of the I/O revamp but I felt it didn't make much sense to do it before that since performance is such a major consideration and all that is going to change a lot. But we can certainly think about and/or improve the api now. |
I haven't actually tried staged functions at all yet, but somehow I get the feeling that they could have a role to play here. |
FWIW let me revive my previous proposal about using non-standard string literals and a function instead of a macro: #5747 |
@Keno @simonster You can use @JeffBezanson But there's nothing wrong with macros evaluating global constants, right? I mean, that must be how function definitions must work; the compiler works with the type itself, not the symbol you pass in. FWIW there's a precedent for this; You can reuse format strings by wrapping |
Another option would be to have fmt = "$.2d"
@sprintf($fmt, 5) Conceptually this makes a certain amount of sense, and technically it's not hard to do; just have I can turn this PR into a proof-of-concept for this if there's interest. |
If big changes are going to be made to |
For the record, https://github.com/lindahua/Formatting.jl already has thousand separator, and runtime format arguments e.g. using Formatting
fmt = "%'d"
@assert sprintf1( fmt, 1000 ) == "1,000" |
Using |
I really like the |
@JeffBezanson It's not impossible for them to work together, e.g. quote
@sprintf($(Expr(:$, :fmt)), 5)
end would be the quoted version of the above call. And this is not unprecedented either; I've already had to do this before to get various bits of quoting to play nicely with each other. It's ugly but at the same time it's very unlikely you'd want to do this, since if you're already quoting |
The custom |
No, it would enable reusing format strings:
|
But much more importantly: It will be semantically equal to a function call, so that we can have |
Yeah, that's why I advocated that solution in the old issue. I really find this suits better in the other patterns found in Julia. |
This just makes
@printf
and@sprintf
macroexpand their arguments. I don't think there should be any horrible consequences to changing the order of macro expansion, but we could always check that the expression is a macro call before doing this and/or only replace those that expand to strings.The idea of this is to allow, for example
Which is obviously useful when you want to use the same format string more than once.