Always asking for an additional restriction on the base trait.
Some of these restrictions are reasonable, some you need to avoid. Without dyn
the compiler just figures out whether those properties are congruent, with dyn
you need to choose those properties explicitly.
must be
Copy
, must beSend
, must beSized
, must be'static
Send
is typically reasonable and typically can be just added to the list.Sized
- not sure. Idea ofdyn
things typically relies on unsized things (andBox
and friends to get back to theSized
world).'static
- if you are OK at allocating here and there (i.e. not optimising for performance hard), limiting to'static
world (i.e. without other lifetimes and inner references) can be reasonable.Sync
is needed rarely, usuallySend
is enough.Copy
bound is typically too much, unless the data is very simple. Probably you need a.clone()
and/orArc
somewhere.Unpin
can also be just added as needed, unless you are dealing withasync
and optimising allocations.
On and on.
The list of things that can be added in ...
part of dyn Trait + ...
is finite, so this "on and on" won't go forever. So after some time the trait definition and main consumers are expected to stabilise.
I’m off the Golden Path
dyn
road is indeed a thinner and somewhat winding road compared to main, easy way of 'static + Sized
things. But when it is really necessary (i.e. you need dynamically construct the strategies from parts, or you need to attach more strategies from plugins, or you want to avoid big bloated executables), there is little way around it.
So I just embraced the verbosity of using generics and its easy. Yes its more code but its better code.
If it works without dyn
then probably it's OK to leave it that way.
Each of those dyn
, async
, impl<'a>
, Pin
, unsafe
, macro_rules!
things bump Rust experience a step right on Easy-Normal-Hard-Nightmare
scale.
Maybe optional actions (fn action_var(&mut self, var: & Var) -> Option<var>
) can be take argument by value if you roundtrip it back?
fn action_var(&mut self, var: Var) -> Var</var>
hyper-util
It is not released to crates.io as of now, even as alpha version.
Update: now it is released. docs.rs
does not show anything yet. There is a pull request about it already though.
This is a #[no_std]
-friendly library for encoding and decoding WebSocket frames.
It does not offer full WebSocket experience like Tungstenite, only the part where you need to deal with bits and bytes.
It works completely without using memory allocator. You meed to assemble WebSocket messages chunk by chunk yourself though.
Low-level HTTP 1 and 2 processing library "hyper" gets released.
It contains fewer features than 0.14, (relatively) "high-level" client and server are gone. Only hyper::{client,server}::conn
remain.
Also there is some IO abstraction: though it still depends on Tokio (only the sync
feature), it should be easier to connect other runtimes. Just using it with Tokio like before is though less straightforward.
---
Do not hurry to upgrade your project from 0.14
to 1
, better wait for better support in the ecosystem.