Re: [PATCH v4 2/7] rust: types: introduce ForLt base trait for CovariantForLt
Miguel Ojeda <[email protected]>
| Newsgroups | dev.linux.lists.nova-gpu,dev.linux.lists.driver-core,org.freedesktop.lists.dri-devel,org.kernel.vger.linux-kernel,org.kernel.vger.linux-pwm,org.kernel.vger.rust-for-linux |
|---|---|
| Message-ID | <CANiq72nr6UD=W6oFsJQaGrSFCRqyWnY80=SyNR7u6=eVQ7ci=Q@mail.gmail.com> |
On Sat, Jun 27, 2026 at 3:51 PM Danilo Krummrich <[email protected]> wrote: > > The only way this could silently break would be to use ForLt!(), but then don't > use the explicitly provided safe cast_ref() method, and instead open-code it > with an unsafe transmute() assuming covariance from ForLt!(). Yeah, that is the not-compile-error case I was considering. i.e. I was trying to think if there could be an issue with the name reuse, since it can always be a pitfall. For in-tree I agree it isn't a problem. For out-of-tree users, given it is very new and it is unlikely they had that case, I think it is also fine. (But e.g. if it were something that had been there for a long time, e.g. in an LTS already, then I would say it would have been better to pick another name). > I can add them on apply, or we leave them as good first issue, as you prefer. Up to you! I didn't want to add noise/nit work, but if it is fixed already, then that is great. [ I also saw some non-Markdown comments in the other commits, e.g. // Invariant ForLt types (e.g. containing a Mutex) in the sample. ] Thanks! Cheers, Miguel