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 0adc1bb161d3f36363cff6f695386a0a2ac36b45, 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.

[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.

[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!