Implement a concat!() format extension #9740
Conversation
|
It seems like the interior expansion could be generalised to something like LaTeX's expand_inner!(foo!(bar!(), baz!()))
// is the same as
foo!("bar", 100)assuming |
|
Oh hm that would be nice to have so we don't have to re-implement it for each thing individually. I suppose though that |
|
Yeah, I agree that it's not simple: I think either we just say "expand_inner only works with comma-separated exprs", or somehow override the |
|
@alexcrichton @huonw is this worth holding back for an |
|
I have no particular opinion either way. |
|
I'm not seeing how this would get implemented with an inner-expansion macro. The reason macros don't do that right now is because they don't know that they have sub-expressions. I don't mind implementing another convenience macro, but I'm not sure what it would look like (which is why I'd still like to merge this). |
This extension can be used to concatenate string literals at compile time. C has
this useful ability when placing string literals lexically next to one another,
but this needs to be handled at the syntax extension level to recursively expand
macros.
The major use case for this is something like:
macro_rules! mylog( ($fmt:expr $($arg:tt)*) => {
error2!(concat!(file!(), ":", line!(), " - ", $fmt) $($arg)*);
})
Where the mylog macro will automatically prepend the filename/line number to the
beginning of every log message.
This extension can be used to concatenate string literals at compile time. C has
this useful ability when placing string literals lexically next to one another,
but this needs to be handled at the syntax extension level to recursively expand
macros.
The major use case for this is something like:
macro_rules! mylog( ($fmt:expr $($arg:tt)*) => {
error2!(concat!(file!(), ":", line!(), " - ", $fmt) $($arg)*);
})
Where the mylog macro will automatically prepend the filename/line number to the
beginning of every log message.
|
oh dear... oh dear... local-expand is really scary. @alexcrichton, @huonw, Have you guys thought about how this affects hygiene? |
|
Sadly not a whole lot. I imagine that yoiu're much more qualified to think about that than I am, but at least for the time being local-expand is only really useful when things are constants and/or take no arguments. The only use case for this is concatenating strings and getting a string literal for a format string, so I don't think that it will affect any existing code today unless we start using it elsewhere (which we probably shouldn't from what it sounds like). Is there a more proper way to do this? Or is there even a good way to do this at all? |
|
This is only used in the tests in the main codebase, so it could easily be reverted until we have resolved hygiene issues. |
|
I'm furiously re-reading MTWT right now. Let me see what I can come up with. Racket does support local-expand, but there's some really complex machinery that goes along with it, that we don't have and probably don't want. |
|
okay, I just posted to the racket list... let's see what they can add, if anything. |
This extension can be used to concatenate string literals at compile time. C has
this useful ability when placing string literals lexically next to one another,
but this needs to be handled at the syntax extension level to recursively expand
macros.
The major use case for this is something like:
Where the mylog macro will automatically prepend the filename/line number to the
beginning of every log message.