Hacker News new | ask | show | jobs
by djmcnab 1525 days ago
A change I find interesting in this release is the addition of `Deref`/`DerefMut` derives[0]. It addresses a very real pain point in bevy, due to `#[derive(Component)]`'s interaction with the orphan rules requiring newtypes[^1].

But it's potentially not idiomatic within the Rust language, at least at the moment (as mentioned in the OP). However, I think that the tide is likely to turn on that; for example, in the api-guidelines repo, there's a PR[2] to remove this advice. This appears to have stalled, although that appears to be not for reasons of it being controversial, just lack of reviews; the discussion had broad support.

We have discussed (in Discord[3]) a kind of 'internal' `Deref`, which would use lenses to do automatic unwrapping for queries. See #4413 [4] for an example of what this would look like. I'm not sure how necessary that is if we can just use `Deref[Mut]`, but it's definitely another angle we could go down long-term.

[0]: https://bevyengine.org/news/bevy-0-7/#deref-derefmut-derives

[^1]: This newtype requirement isn't a negative for bevy, since it makes it much easier to avoid interoperability headaches between different crates.

[2]: https://github.com/rust-lang/api-guidelines/pull/251

[3]: https://discord.gg/bevy

[4]: https://github.com/bevyengine/bevy/pull/4413

1 comments

I hope the tide does turn and then keeps going. I think the language restrictions around Deref(Mut) and Index(Mut) originally borne of purism are just not all that helpful in practice. I can make a network request in my Deref impl, but I can't return a smart pointer?
The danger with DerefMut is that one may accidentally allow violating the type's invariant. Same with Deref when interior mutability is present.