Add methods for unchecked casting of Any objects. #14217
Conversation
This is definitely unsafe behaviour, but for certain cases it can be useful, such as when boxing a value and immediately wanting a reference to the value as the appropriate type, or when one has already used `is` and is thus certain of the type and so wishes to skip the redundant check. It'd be handy if we could then implement the checked ones (`as_ref`, `as_mut_ref` and `move`) on the traits as default methods, but no can do there, because of the `is(self)` method calling: an implementation for the trait objects it will autoreborrow, but in a default implementation it will consume, so we can't do it that way without restructuring at least `is` to take `&self`, which may have other issues (?), and making `AnyMutRefExt` and `AnyOwnExt` extend `AnyRefExt`.
|
(This is an unsolicited contribution; I expect it to be looked on with deep suspicion and will not be surprised if it is rejected.) As a demonstration of where I want this stuff, my header representation scheme in Teepee needs this for optimal efficiency. In src/httpcommon/headers/mod.rs I define The usage of the unchecked methods is in src/httpcommon/headers/internals.rs, lines 125-126 and 155-156: box a value of a known type and immediately take a reference to it; no point in paying the Line 135 also demonstrates another case for it, though there it is just a tad bit of convenience in matching which could be eradicated in favour of using the safe interface, at just the cost of slightly uglier code. (I should probably change it anyway.) |
|
I am curious about the whole implement-the-safe-methods-on-the-trait thing; would making |
|
Before putting the effort into rebasing this against upstream changes—is this addition acceptable, O ye members of the core team? |
|
Closing due to inactivity. I'm not sure how far we want to go down this |
|
The inactivity is simply due to me waiting for a decision from the team, so I think that citing that as the reason for closing it simultaneously with giving the opinion originally solicited is not fair. I would say that there is precedent for such things; for example, a string is UTF-8-checked, but there is a method to skip that checking. I demonstrated my use case—though in it for other technical reasons I would not be using the actual implementation of the unchecked methods, rather having to reimplement them for another trait definition, which certainly weakens my position. |
|
You must understand that we are all quite busy people, and sometimes PRs like this fall through the cracks. It is not solely our responsibility to ensure that every last pull request receives a detailed review. It is often up to the contributor to actively seek out review if it appears to be inactive for quite some time. You're always free to reopen this, I've stated my opinion, but mine is far from the only one. |
fix: Watch both stdout and stderr in flycheck Fixes rust-lang#14217 This isn't great because it un-mixes the messages from the two streams, but maybe it's not such a big problem?
This is definitely unsafe behaviour, but for certain cases it can be
useful, such as when boxing a value and immediately wanting a reference
to the value as the appropriate type, or when one has already used
isand is thus certain of the type and so wishes to skip the redundant
check.
It'd be handy if we could then implement the checked ones (
as_ref,as_mut_refandmove) on the traits as default methods, but no can dothere, because of the
is(self)method calling: an implementation forthe trait objects it will autoreborrow, but in a default implementation
it will consume, so we can't do it that way without restructuring at
least
isto take&self, which may have other issues (?), and makingAnyMutRefExtandAnyOwnExtextendAnyRefExt.