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 be Send, must be Sized, must be 'static
Send is typically reasonable and typically can be just added to the list.
Sized - not sure. Idea of dyn things typically relies on unsized things (and Box and friends to get back to the Sized 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, usually Send is enough.
Copy bound is typically too much, unless the data is very simple. Probably you need a .clone() and/or Arc somewhere.
Unpin can also be just added as needed, unless you are dealing with async 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.
Some of these restrictions are reasonable, some you need to avoid. Without
dynthe compiler just figures out whether those properties are congruent, withdynyou need to choose those properties explicitly.Sendis typically reasonable and typically can be just added to the list.Sized- not sure. Idea ofdynthings typically relies on unsized things (andBoxand friends to get back to theSizedworld).'static- if you are OK at allocating here and there (i.e. not optimising for performance hard), limiting to'staticworld (i.e. without other lifetimes and inner references) can be reasonable.Syncis needed rarely, usuallySendis enough.Copybound is typically too much, unless the data is very simple. Probably you need a.clone()and/orArcsomewhere.Unpincan also be just added as needed, unless you are dealing withasyncand optimising allocations.The list of things that can be added in
...part ofdyn 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.dynroad is indeed a thinner and somewhat winding road compared to main, easy way of'static + Sizedthings. 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.If it works without
dynthen 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 onEasy-Normal-Hard-Nightmarescale.