This repository was archived by the owner on Oct 30, 2019. It is now read-only.
RFC: Convert runtime_raw::Runtime to use static dispatch #97
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Changes the primary
runtime_raw::Runtime
trait to use static dispatch, the global runtime then uses an adaptor that can convert any runtime implementation into a dynamically dispatched one.Motivation and Context
This was spawned out of an idea I had about getting runtime closer to something that could be used without
alloc
, discussed on Discord from about here.One of the points brought up was how
Runtime
might relate to external defined existential types, it's not mentioned in that RFC, but from testing the current existential type implementation it appears that using associated types through an existential type should work. Using a trait definition like this could result in whole program monomorphisation to the chosen runtime.My current implementation uses the
type_alias_impl_trait
feature, this is used for two reasons:<runtime_native::Native as Runtime>::TcpStream == runtime_native::Compat<romio::net::TcpStream>
.These could both be avoided by just boxing everything, but that would result in double boxing once the
runtime::into_dyn::Dyn
type-erasure is applied. For that reason I think doing this change should be blocked ontype_alias_impl_trait
being usable.I hope to try using this for a whole program monomorphisation by passing a generic runtime around at some point, but I have a feeling that will still be too unwieldy to deal with.
Overall, even if external existential types aren't implemented, and manually emulating them isn't viable, I think this slightly cleans up the actual runtime implementations since they just need to do the mapping to the runtime traits and don't have to deal with the type-erasure as well.
(Includes changes from #96, will rebase once that is merged).
Types of changes