You'd also need a mutable counter-part, and I'm also not sure how casts that take ownership would work. E.g. when you cast something inside the Box you can get an owned type.

I'd also name it as get_as and get_as_mut.

Could we remove the impl <T: Any> stuff from utils?

Not yet, but AsAny is private, and can now continue being so (so the pitfalls from the T: Any impl aren't as perilous).

You'd also need a mutable counter-part, and I'm also not sure how casts that take ownership would work. E.g. when you cast something inside the Box you can get an owned type.

Added as_inner_mut and into_inner in second and fourth commit.

I'd also name it as get_as and get_as_mut.

I chose as_inner to be more closely aligned with the C-CONV Rust API guideline.

I chose as_inner to be more closely aligned with the C-CONV Rust API guideline.

There's nothing inner though, you just try to get by doing a cast, hence get. Usually such methods are named cast. Inner just isn't it.

Not yet, but AsAny is private, and can now continue being so (so the pitfalls from the T: Any impl aren't as perilous).

The point was that it's easy to mess things up with it, thus I want it removed. Not as any, but the T: Any impl.

I chose as_inner to be more closely aligned with the C-CONV Rust API guideline.

There's nothing inner though, you just try to get by doing a cast, hence get. Usually such methods are named cast. Inner just isn't it.

I'd probably be fine with cast, cast_mut and cast_into. Or cast_ref, cast_mut and cast?

Not yet, but AsAny is private, and can now continue being so (so the pitfalls from the T: Any impl aren't as perilous).

The point was that it's easy to mess things up with it, thus I want it removed. Not as any, but the T: Any impl.

But the problematic part isn't actually the as_any, nor the T: Any impl; the problematic part is the combination of .as_any().downcast_ref::<X>().unwrap(). And I believe that when using .as_inner::<X>().unwrap(), those problems are no more.

If you want, we can rename the as_any/... methods to something like __as_any to signify that they should be avoided?

I mean, my solution solved all of that, method was present only where it was needed and expected.

I mean, my solution solved all of that, method was present only where it was needed and expected.

Yeah, but it also introduced an extra API that all backends have to implement, which feels ugly IMO.

Besides, regardless of resolving the problem at hand, I believe the methods as_inner/... I propose here will be valuable conveniences to users (i.e. I will want them even if we go with #4157).

Sure. The reason why I've brought the API is to ensure that the casts actually cast to the right thing, despite of how we write them and e.g. you won't be tempted to use as_any because it's present for the user.

Like I was debugging an issue where my cast wasn't working during implementing an API, thus I wanted some mechanism in place to prevent issues like that to ever appear. Yes, it results in a bit more code to get things more type-safe, because of rust's implicit Deref.

Like I was debugging an issue where my cast wasn't working during implementing an API, thus I wanted some mechanism in place to prevent issues like that to ever appear. Yes, it results in a bit more code to get things more type-safe, because of rust's implicit Deref.

I fully agree that this is a big issue, and that we should resolve it!

I've renamed the AsAny trait methods to __as_any/__as_any_mut/__into_any, and marked them #[doc(hidden)], that way, they shouldn't show up even to rust-analyzer (and again, in the future, AsAny will be completely gone).

My biggest problem with T: OpaqueObject is that it won't really help once rust-lang/rust#65991 is usable by us, since at that point you can convert any &T -> &dyn Any anyhow.

Rename to cast_ref, cast_mut, and cast. Since we logically upcast -> downcast, hence cast.

Done.

I think I slightly prefer cast/cast_mut/cast_into, since I think &dyn Window -> &T is going to be the most common operation, but I also like cast_ref/cast_mut/cast, since it mirrors the std API.

@madsmtm could you check if the latest commit is fine? I just don't like that we'd have to duplicate the actual code for pretty much every opaque object we add into the winit-core, thus it'll add required cast methods.

We could probably use a macro_rules! though instead to add a proper bound for such calls as alternative.

Added one more commit that restricts the casting, but uses macro for that. I think bounding by the trait in cast is a good idea, and probably I'd rather go with it.