Allow deriving protocols with Any

[ModProg]

Usage

#[derive(Any, Clone, Display, Debug)]
#[rune(item = ::std::env, protocols(STRING_DISPLAY, STRING_DEBUG, TRY=Self::branch))]
#[display("{}", value.as_deref().unwrap_or_default())]
#[debug("{name}={:?}", value.as_deref().unwrap_or_default())]
struct Var {
    name: String,
    value: Option<String>,
}

impl Var {
    fn branch(self) -> Result<Self, Result<(), Error>> {
        if self.value.is_some() {
            Ok(self)
        } else {
            Err(Err(anyhow!(
                "Environment variable `{}` not set.",
                self.name
            )))
        }
    }
}

fixes #583

[ModProg]

One thing to decide is whether to require the Self:: as protocols are likely often associated functions.

This would mean that:

1. external functions need a qualification i.e. super::something or similar
2. functions in the containing module would need to be specified with self::something.

So this would boil down, would we rather require Self on associated functions or self on non-associated functions.

[ModProg]

This now also includes 0adc1bb, which is related but not equivalent for associated functions.

#[derive(Any, Clone)]
#[rune(item = ::std::env)]
#[rune(functions(Self::is_set))]
struct Var {
    name: String,
    value: Option<String>,
}

impl Var {
    #[function]
    fn is_set(&self) -> bool {
        self.value.is_some()
    }
}

[ModProg]

Also, very much WIP, if you agree overall, I'll add the missing traits. And we'll also need documentation and tests.

[udoprog]

Thanks!

I'm out now! I'll check it out when I get back next week.

[udoprog]

Great feature, thank you!

Documentation and tests and I'd consider it done, even if we need to add more protocols later on.

The one nit I have about syntax is that I'd probably prefer the use #[rune_derive(..)] and #[rune_functions(..)] over #[rune(protocols(..)) and #[rune(functions(..))]. I'm not a huge fan of nested attributes.

Regarding naming, what do you say?

[ModProg]

The one nit I have about syntax is that I'd probably prefer the use #[rune_derive(..)] and #[rune_functions(..)] over #[rune(protocols(..)) and #[rune(functions(..))]. I'm not a huge fan of nested attributes.

whatever you prefer, I don't have a strong feeling there.

[ModProg]

@udoprog what is your opinino on this?

One thing to decide is whether to require the Self:: as protocols are likely often associated functions.

This would mean that:

1. external functions need a qualification i.e. super::something or similar

2. functions in the containing module would need to be specified with self::something.

So this would boil down, would we rather require Self on associated functions or self on non-associated functions.

[udoprog]

Seems fine. For the way it's implemented you should even be able to omit self:: if the function is unambiguous.

[ModProg]

Seems fine. For the way it's implemented you should even be able to omit self:: if the function is unambiguous.

currently yes the question was about changing this, i.e. making single ident function names be associated by default and only resolve paths relatively to the module.

i.e. "the_fn" would be "Self::the_fn" and "self::the_fn" would be "self::the_fn", i.e. the containing module.

Currently it is "Self::the_fn" is "Self::the_fn" and "the_fn" would resolve to "self::the_fn" i.e. the containing module.

[udoprog]

Oh I see. Well, then no. Let them resolve to whatever path they're part of? They're declared within an impl that sees Self, so that ends up being a legal path. I don't see the reason why you'd want to make it more explicit.

[ModProg]

@udoprog The docs for the Any macro are actually not shown. Not sure if that is due to being reexported again at the crate root.

[ModProg]

AFAICT the only way around that, is moving this reexport in the crate root.

[ModProg]

rust-lang/rust#81893

[udoprog]

Welp, time to move!

[ModProg]

So what would be your preference? Add the documentation in rune-macros or in rune's lib.rs?

[udoprog]

Move the re-export and document it. Otherwise you have a circular dev-dependency for any doc tests that uses rune which rust-analyzer does not like. And all the documentation in one place.

[udoprog]

PR looks to be in pretty good shape with a few things that can be done later. Would you be OK with me going over, clean a few things up and merging it?

[ModProg]

PR looks to be in pretty good shape with a few things that can be done later. Would you be OK with me going over, clean a few things up and merging it?

Sounds good.

IIRC one thing that needs fixing is the String type in DISPLAY_STRING. Either, rune needs a rune::__private::String that maps to the correct String dependent on if std is present. Otherwise, one could also have a feature in rune-macros for std.

[Roba1993]

What is blocking this feature right now? I would be really interested for this functionality.

[udoprog]

Rebasing, cleaning up the PR, and bandwidth.

I'll have another stint working on Rune eventually, and then I plan to pick it up again. But if you're interested, please go ahead!