transform the return value of `Result` and `Option` type about rust-delegate HOT 8 CLOSED

I don't like piling new and new attributes into this crate

yeah, I agree. at this point, I also felt the heavy annotation is overwhelming and the added noise might already over weighted the benefit of using macros to reduce boilerplates. it's definitely not the right direction to go to make the library over complicated. my initial motivational use case was a one-off situation anyway.

I think it's good to close this for now; maybe we can re-open it if the idea gets clearer and more mature.

from rust-delegate.

I suppose that the question mark operator is common enough to warrant a special attribute. But at this point, I wonder if we should just create some generic expr wrapper, like

struct Wrapper(Foo);
impl Wrapper {
    delegete! {
        #[expr(Ok($expr?))]
        to self.0 {
             fn foo(&self) -> Result<..., ...>;;
             fn bar(&self) -> Result<..., ...>;
        }
    }
}

from rust-delegate.

I wonder if we should just create some generic expr wrapper, like

I like the idea of a generic solution. as for the syntax of the placeholder $expr, I think a shorter sigil is enough, like a single $ sign or something. on the other hand, $expr is more extensible (to support potential new features). I don't really know which way I like more, maybe you have better ideas in mind?

from rust-delegate.

I guess that it will depend on what will be the easiest to parse with syn, I'm not even sure if we can start the sigil with $. I'm leaving for a two week vacation now, so I won't be able to work on this now, I'll experiment with it in September.

from rust-delegate.

Hmm, $ nor $expr can be parsed as an expression with syn. And also I realized that this would clash with the to <expr> target expression a little bit. Ideally we would be able to say something like delegate! { to Ok(self.foo.$call) }, but this conflates two things - the target of the call (self.foo) and an additional "wrapping" expression around the resulting call (Ok(...)). And also this syntax wouldn't work, because sometimes the call can be performed with :: instead of . (for associated functions).

from rust-delegate.

delegate! { to Ok(self.foo.$call) }

yeah, too much is going into a single syntax form, and that looks complicated to me. it would be good for a general solution, but I think for now, make the question mark operator a special case is acceptable.

my first thought was maybe we can decorate the function signature a little bit, similar to how function parameters can be transformed in current version, something along the lines of:

delegate! {
    to self.0 {
        // this syntax?
        pub fn foo(&self, #[into] other: Self) -> #[Ok(?)] Result<isize, Self::Error>;
        // or this?
        pub fn foo(&self, #[into] other: Self) -> #[map_err] Result<isize, Self::Error>;
        // or even this?
        pub fn foo(&self, #[into] other: Self) -> ? Result<isize, Self::Error>;
        // but it feels too complex if we want to fit too much features
        pub fn foo(&self, #[into] other: Self) -> #[ok_or(Error::DataEmpty)] Result<isize, Self::Error>;
    }
}

looking into the documents, I find that currently we support #[unwrap], #[try_into], #[into], I think it would be reasonable to add the opposite of #[unwrap], I don't have a suitable naming yet, maybe something like #[Ok] and #[Some], (and by extension, an variant form like #[Ok(?)], although it would be useless for a #[Some(?)]), this should coverage the common use cases of the form Ok(self.inner.foo()?) I think.

from rust-delegate.

I'm still unsure about this, as I don't like piling new and new attributes into this crate. I think that some experimentation with the placeholder syntax (like #[wrap(Ok(_)?)]) could be nice, but I don't currently have time to play with it. I'd be happy to accept PRs where we could discuss a specific implementation though :)

from rust-delegate.

Ok :) Closing for now.

from rust-delegate.