Open sdupille opened 7 months ago
@sdupille while we technically can make World
macros desugaring supporting lifetimes in World
to some extent, it's still not applicable by the whole design.
Let's leave concrete types for a moment, and look at the bigger picture here:
World
instance is created by the framework for each scenario.World
is controlled by the framework. For the user code (step functions) there is no control over it. The framework decides when to destroy or where to pass the World
(and it's not something deterministic).World
a lifetime parameter, means that it's not self-contained anymore, and depends on a lifespan of some other object.World
, which has the larger lifespan and is controlled by the framework, to refer/depend on an object living in a shorter lifespan of the step function.World
can refer to is either some global data (meaning 'static
usage), or itself (self-referential stuff).So, there can be several ways to deal with your problem:
Intersection<'a>
/WorldItem<'a>
point to into the World
too, making it self-referential. Crates like owning_ref
or ouroboros
should help here.Intersection<'a>
type (i.e. IntersectionOwned
) and use it.Intersection<'a>
points to, overlives the World
, created by the framework on demand and being Drop
ed who-knows-where (may be at the end of the program), you may unsafe { mem::transmute() }
lifetime into a 'static
one.
Hey there ! I wrote a lib I want to test with cucumber. My lib use some struct that has some lifetimes, like this :
And I need to store these kinds of values in cucumber world. So, obvious solution was to create a world object with lifetime, like this :
But it doesn't work, and the message is weird :
I also have a bunch of errors like this :
How can I create a world with lifetime ? Is there a way ? If not, any workaround ?