proposal: extend netip.Addr support to ipv6

[costela]

netip.Addr supports parsing both ipv4 and ipv6 out of the box. So it is a bit surprising to have a netip.Addr field in an API only support ipv4 and no easy way to add "dual-stack" support for APIs.

I propose to extend the support for netip.Addr added in #396 and support ipv6 out of the box as well.

⚠️ The change in the format detection for netip.Addr fields may be considered breaking, since existing APIs will start accepting IPv6 addresses and people may be counting on that limitation. I'd argue that it's worth it, but if not, we can remove that single change, while still adding support for the ip dual-stack format, to be used explicitly.

WDYT?

[Copilot]

Copilot reviewed 6 out of 6 changed files in this pull request and generated no comments.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 93.11%. Comparing base (58aba1e) to head (896acfb).

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #792   +/-   ##
=======================================
  Coverage   93.10%   93.11%           
=======================================
  Files          23       23           
  Lines        5296     5300    +4     
=======================================
+ Hits         4931     4935    +4     
  Misses        313      313           
  Partials       52       52           

☔ View full report in Codecov by Sentry.
📢 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.

[costela]

Taking a second look at this, it appears it is possible to support dual-stack input by setting format:"ipv6", because IP.To16 also works for ipv4.

That doesn't seem very intuitive and could maybe warrant a doc fix?

Personally I'd try making this a bit more explicit: the ipv4/ipv6 formats should really be specific to their respective IP versions, and a new ip format should support both. WDYT?

Also, it may be a good idea to switch to netip for all validations regardless, just for the micro-optimization:

pkg: github.com/danielgtaylor/huma/v2
cpu: 12th Gen Intel(R) Core(TM) i7-1250U
BenchmarkNetParseIP-12               31314682                32.42 ns/op           16 B/op          1 allocs/op
BenchmarkNetipParseAddr-12           72398744                15.65 ns/op            0 B/op          0 allocs/op

[danielgtaylor]

@costela I love this! One concern I have is that ipv4 and ipv6 are actually in the JSON Schema spec but ip is not. See https://json-schema.org/understanding-json-schema/reference/type#ip-addresses.

I wonder if we should support all three? The two standard ones, and then ip for either one since Go supports it well. What do you think?

edit: just saw your other comment which is similar to mine, sorry 😂