Closed msrd0 closed 9 months ago
You have to add ref
before foo
in MyWidgetMyEvent(foo)
like in MyWidgetMyEvent(ref foo)
.
See this example.
Is there a reason why you force the &
in the relm::connect_stream!
macro? It seems to compile just fine when the &
is removed.
I'm not sure exactly where &
you're talking about, but I think I understand your question anyway.
Both the current widget and parent widgets can see the same message. The current widget gets an owned version of the event, but to avoid a clone, the parent widgets get a reference.
I'm talking about this one: https://docs.rs/relm/0.24.0/src/relm/macros.rs.html#113. It is the source for the &$message
part in the error message.
As far as I understand it, the parameter passed by observe
is already borrowed, so match msg
will match a reference anyways. I tried removing the &
and at least for my code, it works without any problems and I don't need the ref
. Compiling all your tests is really annoying as all of them compile into their own target folder which takes forever, so I didn't try.
Oh, that's because of match ergonomics: the Rust compiler automatically adds the &
and ref
for you.
I find this leads to worse error messages which is why I prefer to avoid it.
Well, it doesn't add the ref
if you manually add the &
, so I feel like right now it creates error messages where it would otherwise compile.
There might be other cases where this isn't the case that I just haven't found yet of course.
Well, it doesn't add the
ref
if you manually add the&
, so I feel like right now it creates error messages where it would otherwise compile.
Indeed, Rust won't do match ergonomics if you add *
or &
. That's the reason &
is used in the macro: I wanted to disable match ergonomics.
Whenever I have a message type that is non-Copy, e.g.
Then I cannot use this message, or otherwise I get a compilation error:
The error message is
This is impossible to fix in user code, using e.g.
Msg::MyEvent(foo.clone())
orMsg::MyEvent((&*foo).into())
produces the exact same error message. The problem is within the macro-generated code that produces&MyWidgetMyEvent(foo)
. I believe this could be fixed by emiting&MyWidgetMyEvent(ref foo)
, but I haven't tested that.