Allow argument in macro to be Option<T> or T
from silva@sopuli.xyz to rust@programming.dev on 16 Jun 2024 07:48
https://sopuli.xyz/post/13861471
from silva@sopuli.xyz to rust@programming.dev on 16 Jun 2024 07:48
https://sopuli.xyz/post/13861471
Hey,
Is there any way to create a macro that allows a Some<T> or T as input?
It’s for creating a Span struct that I’m using:
struct Span {
line: usize,
column: usize,
file_path: Option<String>,
}
…and I have the following macro:
macro_rules! span {
($line:expr, $column:expr) => {
Span {
line: $line,
column: $column
file_path: None,
}
};
($line:expr, $column:expr, $file_path: expr) => {
Span {
line: $line,
column: $column
file_path: Some($file_path.to_string()),
}
};
}
…which allows me to do this:
let foo = span!(1, 1); let bar = span!(1, 1, "file.txt");
However, sometimes I don’t want to pass in the file path directly but through a variable that is Option<String>. To do this, I always have to match the variable:
let file_path = Some("file.txt");
let foo = match file_path {
Some(file_path) => span!(1, 1, file_path),
None => span!(1, 1),
}
Is there a way which allows me to directly use span!(1, 1, file_path) where file_path could be “file.txt”, Some(“file.txt”) or None?
Thanks in advance!
threaded - newest
Option<T>has aFrom<T>implementation that lets you writeOption::from($file_path).map(|path| path.to_string())to accept both cases in the same expression.doc.rust-lang.org/std/option/enum.Option.html#imp…
This does not work, as rust cannot infer the type of
pathA generic impl is impossible.
Imagine you want to turn a
Into<String>toSome(val.into())andOption<Into<String>>toval.map(Into::into).Now, what if there is a type
Twhereimpl From <Option<T>> for Stringis implemented?Then we would have a conflict.
If you only need this for
&strandString, then you can add a wrapper typeOptionStringWrapper(Option<String>)and implementFrom<T> for OptionStringWrapperfor all concrete type cases you want to support, and go from there.Right, there may be too many unknowns involved. 🤔
.
It’s surprisingly simple: play.rust-lang.org/?version=stable&mode=debug&edi… As a side node, asking for a value, and then immediately calling
to_stringon it seems kinda hiding the allocation. I’d suggest let the user callto_stringon it themselves.(e) Changed it a bit to account for passing
Noneas the third argument.I think the point is that the variable itself is an Option. Your example only works for literal Option (although the value inside the optional itself might not be a literal).
One option to OP’s problem is to use an auxiliary trait implemented on both string and Option<string>
This looks something like the following
play.rust-lang.org/?version=stable&mode=debug&edi…
* Two of your macro rules are not used 😉 (expand to see which ones).Option<&str>. If it did, we would lose literalNonesupport 😉Similar impl, but using wrapper struct with
FromimplsThe macro rules are all used. (Macros are matched from top to bottom by the declared match types. The ident/expressions can’t match until after the more text based Option matching.)
let _foo = Span { line: 1, column: 1, file_path: None }; let _bar = Span { line: 1, column: 1, file_path: "file.txt".upgrade() }; let _baz = Span { line: 1, column: 1, file_path: Some("file.txt".to_string()) }; let _baz = Span { line: 1, column: 1, file_path: None }; let _baz = Span { line: 1, column: 1, file_path: borrowed.upgrade() }; let _baz = Span { line: 1, column: 1, file_path: owned.upgrade() };I didn’t make Option<&str> an option because the struct is for type
Option<String>. It does support Option<String> though.impl OptionUpgrade for Option<String> { fn upgrade(self) -> Option<String> { self } }It looks like the following, and uses the last match case.
let opt: Option<String> = Some("text".into()); let opt = span!(Oops. I was looking at it wrong.
Re-read the end of OP’s requirements.
I made an edit.
There’s not anything stopping it from supporting Option<&str> though. This would be the implementation
impl OptionUpgrade for Option<&str> { fn upgrade(self) -> Option<String> { self.map(|v| v.into()) } }It’s also possible to just make it generic over Option types
impl<A: ToString> OptionUpgrade for Option<A> { fn upgrade(self) -> Option<String> { self.map(|v| v.to_string()) } }Yes, but then the concrete type of
Noneliterals becomes unknown, which is what I was trying to point out..
Why not add a
new()function that does the same? Macro seems unneccessaryYou might be okay with this:
macro_rules! span { ($line:expr, $column:expr) => { Span { line: $line, column: $column, file_path: None, } }; ($line:expr, $column:expr, $file_path:literal) => { Span { line: $line, column: $column, file_path: Some($file_path.to_string()), } }; ($line:expr, $column:expr, $file_path:expr) => { Span { line: $line, column: $column, file_path: $file_path, } }; }Playground
Essentially I took this to mean
strliterals will be auto wrapped inSome, but anything else is expected to beOption<String>