While this is true, it is kind of orthogonal to the issue here, since the macro correctly guessed that `&str` referred to a borrowed string and generated code for it.

The issue was that the deserializer could produce non-borrowable strings at runtime, which cannot be used to create an instance of this type and hence caused a runtime panic.

Catching this should be possible (even without precise type informations) but I'm not sure it can be done without breaking changes to the Deserializer trait. It would also suffer from false positives since sometimes you might know that the inputs you will deserialize only include strings that can be deserialized in this way.