So far, the only possible way to make this work I could think of would be to have lazy_static!'d strings I can write to from my string deduction function, but I would rather not have mutex unsafe global soup (and having already tried this, I don’t think I can even make that work, I’ll need drop types in static).

Is there a more Rustic way to obey this trait bound but still return runtime deduced strings? The absence of self in the trait methods makes me think I’m stuck. I’m just looking for some way to construct this type and obey this trait while providing strings somewhere for this function to return.

You could use the leak crate, which can convert String to &'static str. As the name suggests, the memory will be leaked and won’t be reclaimable until the process exits, so you’ll probably want to at least cache it somewhere.

Can you file a bug report against that crate? A Cow<'static, str> would be more appropriate if they don’t want to deal with arbitrary lifetimes. Do you happen to know why they require a static string?

I did file a bug against the crate, but do want this working in the in meantime. The leak strategy seems like an alright stopgap.

They aren’t returning Cows because right now there is simply no way to get a dynamic runtime string in the trait fn impl body without a self reference. Implementation wise, this struct is being used as a way to get polymorphic urls per API target without having to provide them as a contiguous object (the actual structs that parameterize them hold them as PhantomData).

How dynamic are the strings you want? Could you maybe codegen them at compile time into literals?

I’m getting these strings from a json response object, so they are pretty much as dynamic as they can get. No way to deduce them in macros until after a full round trip.