KevinPFleming[m] has quit [Quit: Idle timeout reached: 172800s]
phycrax[m] has joined #rust-embedded
<phycrax[m]>
Could someone explain what is going on here? Context: I have an UART display that I draw UI on. My application is abstracted enough that I can run on host, with and without the display connected. The code was fine until I added another seemingly innocent UI element, which fails to compile. I don't know why trait solver (not sure what it is called) is behaving like this.
<JamesMunns[m]>
Generally, I don't _think_ inference changes are considered breaking changes, or at least sometimes they are not
<JamesMunns[m]>
but the issue here is that you have multiple potential impls, and inference is picking the wrong one
<JamesMunns[m]>
So either you need to remove the conflicting impls (the first option I had), or be specific about which impl you want to use (the second option I had)
<JamesMunns[m]>
I think another thing is that that blanket `impl<T> Draw<SimDisplay> for T` is doing is potentially implementing `impl Draw<SimDisplay> for &mut View {}`
<JamesMunns[m]>
not sure exactly how to get the compiler to spit out what it picked for inference at a call site, but IMO the issue is like I said before: there are multiple potential inference targets here, so you'll generally want to be more specific.
<phycrax[m]>
JamesMunns[m]: This is it, changing the fn sign to view: &View solves it. Thanks James! I will try a different approach.
az1[m] has joined #rust-embedded
<az1[m]>
In theory you should be able to see the type inference with rust-analyzer with e.g. vscode. I'm not seeing anything useful with Helix tho so. vOv
<phycrax[m]>
Never thought about blanket impl also implementing for &mut View, TIL!
<JamesMunns[m]>
and `&View`, and `&&mut View`, and...
<JamesMunns[m]>
blanket impls are spicy!
<az1[m]>
Persoanlly I'd think about refactoring it so you don't need a blanket impl.
<phycrax[m]>
I like to slap derive Debug to my UI stuff and have SimDisplay print them out, so I want to keep blanket impl.
<phycrax[m]>
I can come up with a different trait I guess. Maybe a trait for Displays instead of Views could be better.
<az1[m]>
Have you looked at how desktop apps do it? I think elm-style stuff (e.g. ratatui, iced) fits nicely with rust and it would seperate out your rendering.
<az1[m]>
Alternatively yes, a trait that provides some rendering primitives would still let you have a no-op implementation thath just prints out debug info.
<phycrax[m]>
I was thinking about using ratatui instead of just printing out. I will give ratatui a try whenever I find the chance
<phycrax[m]>
I need to develop a couple other terminal apps for DFU and other stuff anyway.
rainingmessages1 has quit [Quit: bye]
rainingmessages1 has joined #rust-embedded
chemoton has joined #rust-embedded
chemoton has quit [Quit: chemoton]
chemoton has joined #rust-embedded
chemoton has quit [Client Quit]
jistr has quit [Ping timeout: 240 seconds]
jistr has joined #rust-embedded
jistr_ has joined #rust-embedded
jistr has quit [Read error: Connection reset by peer]
korbin[m] has quit [Quit: Idle timeout reached: 172800s]
RobinMueller[m] has quit [Quit: Idle timeout reached: 172800s]