feat: add Go 1.27 generic parsing methods to Context

[cxlblm]

Summary

This PR adds Go 1.27 generic parameter parsing methods to Context.

The new methods support:

• Parsing path parameters
• Parsing single and multiple query parameters
• Parsing single and multiple form values
• Providing default values through the Or variants
• Passing parsing options, such as custom time.Time layouts

GoDoc comments and test coverage are included for all new methods.

Examples

id, err := c.ParsePathParam[int]("id")
page, err := c.ParseQueryParamOr[int]("page", 1)
tags, err := c.ParseFormValues[string]("tags")

Testing

The added tests cover:

• Successful value parsing
• Missing parameters
• Invalid values
• Default-value behavior
• Multiple values
• Parsing options

All packages have also been verified to compile with Go 1.27.

Additional context

This is my first contribution to the Echo project.

I used AI-assisted development while working on this change. I have reviewed the generated changes and verified them with the relevant tests.

If there are any concerns about the API design, naming, implementation, or test coverage, I would be happy to discuss them and make the necessary adjustments.

[aldas]

relates to #3066

[aldas]

looks ok, but could you use table based tests

[cxlblm]

looks ok, but could you use table based tests

Do you have any other suggestions for naming this function? I’m not entirely sure whether the current name is appropriate.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 95.72%. Comparing base (dcb05f0) to head (ae64791).
⚠️ Report is 11 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #3069      +/-   ##
==========================================
+ Coverage   93.34%   95.72%   +2.37%     
==========================================
  Files          43       45       +2     
  Lines        4735     4045     -690     
==========================================
- Hits         4420     3872     -548     
+ Misses        192      173      -19     
+ Partials      123        0     -123     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[cxlblm]

That "Parse*" seems little bit redundance. maybe these names as #3066 suggests

Thanks for the suggestion. I agree that the Parse* prefix may look slightly redundant at first.

The main reason for adding it is backward compatibility. Context already has non-generic methods such as QueryParam, QueryParamOr, QueryParams, FormValue, FormValueOr, and FormValues. Since Go does not support method overloading, the new generic methods cannot reuse those names, even if their signatures or type parameters differ.

Reusing those names would require replacing or renaming the existing methods, breaking calls such as:

value := c.QueryParam("page")
values := c.QueryParams()

The Parse* prefix allows the existing raw-value API and the new typed parsing API to coexist:

value := c.QueryParam("page")
page, err := c.ParseQueryParam[int]("page")

Although the path parameter methods do not have the same direct conflict—the existing raw accessor is named Param—using a different naming convention only for path parameters would make the API family inconsistent.

The prefix also makes the type conversion and possible parsing error explicit. Meanwhile, the package-level generic functions can keep the shorter names:

page, err := echo.QueryParam[int](c, "page")

I am open to another non-conflicting naming convention, but removing the prefix entirely would require a breaking API change.

[aldas]

allright, I was just reading this on github web gui and did not actually checked what methods existed. I am sorry for wasting your time. I will do proper review tonight.