API idea: selector!() macro for Selector literals about scraper

[mainrs]

Here is a MVP: https://github.com/SirWindfield/scraper-proc-macro. Compilation fails for one of the tests as the proc-macro panics due to a wrong formatted selector string.

[TonalidadeHidrica]

FWIW I define the following macro that enables caching too.

use once_cell::sync::Lazy;
use scraper::Selector;

macro_rules! selector {
    ($e: expr) => {{
        static SELECTOR: Lazy<Selector> = Lazy::new(|| Selector::parse($e).unwrap());
        &*SELECTOR
    }};
}

[teymour-aldridge]

Why do you think it has to be a macro?

A macro is nicer in this case because it's easier to return compile errors which reduce the need for run-time debugging.

The first thing I did when using this crate is write a function that takes a &'static str, constructs a selector and unwraps the Result.

It is probably useful in some cases to construct selectors dynamically (so either a function taking a String or Cow<'static, str> is helpful there – &'_ str's are harder to manipulate because they are stack rather than heap references).

[Boscop]

The first thing I did when using this crate is write a function that takes a &'static str, constructs a selector and unwraps the Result.
I would like if this function could be included in this crate.
Why do you think it has to be a macro?
(Btw, the regex crate doesn't have that macro.)

[nathaniel-daniel]

A macro is nicer in this case because it's easier to return compile errors which reduce the need for run-time debugging.

How would a macro return a compile-time error?

FWIW I define the following macro that enables caching too.

Wouldn't caching be the only benefit of a selector! style macro?

[teymour-aldridge]

How would a macro return a compile-time error?

There's a compiler built-in macro called [compile_error!](https://doc.rust-lang.org/stable/std/macro.compile_error.html); if a macro outputs that in the code it generates, the compiler fails the compilation and reports the error(s).

[nathaniel-daniel]

Sorry, I meant how would a macro know if a selector was invalid?

[TonalidadeHidrica]

Oops, sorry, I miswrote "too", but my prototype is the one which only enables caching.

[mainrs]

use once_cell::sync::Lazy;
use scraper::Selector;

macro_rules! selector {
    ($e: expr) => {{
        static SELECTOR: Lazy<Selector> = Lazy::new(|| Selector::parse($e).unwrap());
        &*SELECTOR
    }};
}

I personally think that there isn't much value in adding this to the library (in its current form). It's easy enough that it can be added to the user's codebase instead and is probably the place where something like this should be added as well.

As far as I can tell there is no way to actually check a static string at compile-time and throw a compilation-error if the string is not valid. Normal macros are just expanded, not evaluated.

Maybe a proc-macro would do the trick (just the idea sketched out):

#[proc_macro]
pub fn make_answer(ts: TokenStream) -> TokenStream {
    if /* first and only argument is a static string */ {
		if Selector::parse(/* first argument */).is_ok() {
        	/* emit "Selector::parse(first arg).unwrap()" */
        } else {
			compile_error!("failed to compile selector string");
        }
    }
}

Probably not the cleanest solution, but I think it would work. It's easy enough to not even require complex library dependencies like syn, since the only check that has to be done is the "token is a static string" check.

[cfvescovo]

I personally think that there isn't much value in adding this to the library (in its current form). It's easy enough that it can be added to the user's codebase instead and is probably the place where something like this should be added as well.

Agree. Maybe an external library, like the one @mainrs provided, is better