lifetimes for StrContext

[slonkazoid]

Please complete the following tasks

• I have searched the discussions
• I have searched the open and rejected issues

winnow version

0.7.12

Describe your use case

parser generates errors that are dependent of the lifetime of the input. would like to use what it expects in a StrContextValue::Description, which uses the same lifetime

Describe the solution you'd like

add a generic lifetime to StrContext

Alternatives, if applicable

Cow<'static, str> instead of &'static str but this is more expensive in multiple ways

Additional Context

using jaq-core
already implemented and ran tests for it in #806

[epage]

Can you provide examples of what dynamically generated context you are trying to create?

Is there a reason that providing a custom context would not work?

My overall concerns is around the performance trap when using the allocations with backtracking. Defaulting to non-allocating Context steers people to better performance results.

As a secondary effect, this would make things less ergonomic (the ergonomics are already not great).

[slonkazoid]

i replied 8 hours ago but github downtime happened so it did not go through. resending the email did not work either

Can you provide examples of what dynamically generated context you are trying to create?
My overall concerns is around the performance trap when using the allocations with backtracking. Defaulting to non-allocating Context steers people to better performance results.

expecting a StrContextValue::StringLiteral that references the input when, for example, requiring a formerly referenced token. doesn't require allocation in that case. i don't need it anymore though so, can't complain much…

As a secondary effect, this would make things less ergonomic (the ergonomics are already not great).

ContextError still defaults to a StrContext with a static lifetime, so, existing code will at most require changes to function signatures. it just lets you opt into using a custom lifetime.
in fact, the only examples i've had to modify to make them compatible were the json related ones. idk why they specify a concrete StrContext when it's a default value for the generic

Is there a reason that providing a custom context would not work?

no! but that can be cumbersome when you just wanna hack something together quickly

[epage]

no! but that can be cumbersome when you just wanna hack something together quickly

That can be said about a lot of different things. For instance, adding this could make hacking around without the need for this harder which is likely the earlier forms of prototyping than with this.

I tend to use a type alias for my Input. Doing similar for an applications error type can make it easier to make adjustments on the fly like this.