Skip to content
This repository was archived by the owner on Oct 30, 2019. It is now read-only.

Conversation

Nemo157
Copy link
Member

@Nemo157 Nemo157 commented Aug 19, 2019

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:

  1. It hides the underlying implementation, otherwise it would be visible that <runtime_native::Native as Runtime>::TcpStream == runtime_native::Compat<romio::net::TcpStream>.
  2. It avoids adding in a box around the connect future.

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 on type_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

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants