Suggestion: Allow ignoring return value of target method about rust-delegate HOT 9 CLOSED

I added support for changing the return type in https://github.com/chancancode/rust-delegate/tree/returntype.
You can now either:

1. Omit the return type, which will just execute the function and return ()
2. Specify a different return type, which will be converted using .into()

Please test it if it solves your use case :)

from rust-delegate.

@Kobzol Thanks :)

I just switched to that branch, and this stopped working:

impl<S: FromPrimitive> Switcher2<S> {
	delegate! {
		target self.switcher {
			pub fn page(&self) -> S;

The target method has a generic return type chosen by the caller:

	pub fn page<T: FromPrimitive>(&self) -> T {
		T::from_usize(self.selected)
	}

I get this error:

error: type annotations needed
error: cannot infer type for T

Probably because of calling .into() in the generated method.
I think it should work when calling Into::<#ret>::into({#body}) where ret = method.sig.output;..

from rust-delegate.

I tried it and it looks like one big headache.

pub fn page(&self) -> S
{
    Into::<S>::into(self.inner.page())
}

Will not work without self.inner.page::<S>, but that I cannot really generate generally, because I don't know if the method is generic.

I'm thinking of making the into optional, like this:

fn method(&self) -> u32;

delegate! {
    target self.inner {
        #[into]
        pub(crate) fn method(&self) -> u64;
    }
}

to make it simpler and generate the Into::<...>::into() machinery only when this opt-in attribute is present.

What do you think?

from rust-delegate.

@Kobzol Yes, I was thinking the same yesterday, it's not possible for rustc to know which source type to use (the T that is Into<S> could be some other type than T itself, but if that's a generic (chosen by caller), it's too many degrees of freedom so rustc gives the error). So yes, it's probably the best to make .into() optional.
Last night I was thinking about using the syntax -> ; for this but that'd be unobvious when someone else (who isn't familiar with this crate) reads it. So yeah, #[into] sounds the more reasonable :)

from rust-delegate.

Ok :) I created a PR for this (#11). Please check if #[into] works for your use case.

from rust-delegate.

@Kobzol Thanks. I just tested it. It works for the generic case when I omit #[into] :)
Btw, generic return types aren't very common, maybe .into() should be the default, and #[no_into] can then be used to prevent this?
At least in this large project where I use delegate a lot, this was the only case that gave an error when .into() was enabled by default.

from rust-delegate.

I'm not sure.
With .into() being optional:

• generic return types work
• if you explicitly change the return type, it will not work

With .into() being default:

• generic return types don't work
• if you explicitly change return type, it works out of the box

Maybe it's just a detail, but I feel that it might be better if things "just work" for the default case (so without changed return type).

• if you use the same return type as in the underlying method, it should just work
• if you explicitly opt-in into changing the return type, you also have to opt-in to #[into], because you changed the type anyway, so you also have to tell the macro about it

On the other hand it might be much more common to want to change the return type than to use a generic return type.

A small thing for this crate I suppose, but still something that might be worth thinking about: keeping into() optional makes this change backwards-compatible.

from rust-delegate.

Yes, both sides make sense. I do think that it probably occurs more often to want .into() than having generic return types chosen by the caller (especially in delegated methods), it's just this particular project that has some special requirements.. (Also GAT workarounds etc.)

from rust-delegate.

I'm leaning a bit towards the #[into] case. We don't have a way of notifying the user about the generic error, since we cannot know if it compiles or not, so he would get a weird compiler error without any explanation. On the other hand changing the return type is an explicit decision, so in that case the user should expect that he has to do something extra to make that work. The delegated methods are anyway usually copy-pasted, so one attribute extra doesn't seem that bad. I'll let this stay opened for a few more days to see if there are any other pboelms and then I'll merge.

from rust-delegate.