"bytes" variants of macros without using the `B` suffix

[xkr47]

IntelliJ IDEA declares r#"..."#B as a syntax error and pretty much stops parsing, so it would be handy if there were additional macros like regexp_bytes!(r#"..."#) to access the same feature.

[Canop]

I'll have a look, but has IDEA's bug been registered ? Can you please provide the link to that issue ?

[nalply]

It also makes wrapping the macros difficult if not impossible.

[Canop]

@nalply Can you clarify what you mean ?

[nalply]

I wanted to create a macro where I can pass a string literal into lazy_regex!().

Something like this:

macro_rules! example {
  { $rx:literal } => { ( $rx, lazy_regex!($rx) ) }
}

This would create a tuple with the literal and the regex, a stupid example, I know, but to show that such things are not possible.

[Canop]

@nalply I think you shoud be able to write something like this:

macro_rules! example {
    { $rx:literal } => {{
        static R: Lazy<Regex> = lazy_regex!($rx);
        ( $rx, &*R )
    }}
}

but it may depends on the real goal.

Unless I'm missing something, this is a very different problem than the original one of @xkr47 . Right ?

[nalply]

but not if you use a byte regex, the B suffix prevents such usage, because the outer macro does not parse the suffix

[Canop]

Ah, OK, now I understand your comment.

[xkr47]

I'll have a look, but has IDEA's bug been registered ? Can you please provide the link to that issue ?

You mean the IDEA would be able to parse the macro and understand that the sequence of tokens are ok? Wouldn't that basically require executing the rust code since it is not implemented with macro_rules!?

[xkr47]

Unless I'm missing something, this is a very different problem than the original one of @xkr47 . Right ?

I guess after the last comment it seems to be actually both would benefit from byte versions of lazy regexp being available as separate macros..?

[nalply]

By the way, sorry to be so vague again, but when editing with helix, rustfmt also seemed to have a problem understanding the B suffix. When saving rustfmt just removed the suffix. I tried different variations till I was successful.

This experience gave me a sinking feeling about the B suffix to be a bad idea.

I am afraid it's not idiomatic Rust. An attribute proc macro only takes valid syntax (afaik). A function like proc macro like lazy_regex!() has more freedom, but in a guide to declarative macros it is said, it is preferrable if the input is structured like real Rust code.

So in a summary, lazy_regex!() violates the principle of idiomatic Rust that macro input is valid syntax, and this causes the problem @xkr47 xkr47 has reported and my own problems, too.

It's up to you, what you can do. I would find these steps sensible:

1. create a new macro which takes options as a different parameter
2. deprecate lazy_regex!()

By the way, thank you for lazy_regex, it is still immensely useful.

[Canop]

But a suffix on string literals is valid in Rust: https://doc.rust-lang.org/beta/reference/tokens.html#string-literals
That's why I say that IDEA refusing it is a bug.

This being said, I've started working on a new version which should have macros with a _bytes suffix, so that B isn't really needed.

[nalply]

Sorry, my bad.

[Canop]

I'd appreciate tests of #31