Fix form binding of Nullables

[mromaszewicz]

Closes: #129

nullable.Nullable[T] is defined as map[bool]T, but neither bindFormImpl nor BindStringToObjectWithOptions had a reflect.Map branch, so any Nullable field in a form body failed with "error binding string parameter: can not bind to destination of type: map".

This change adds Map handling at both layers:

• BindStringToObjectWithOptions (bindstring.go): a bool-keyed map destination is treated as a Nullable wrapper -- bind src into a fresh value of the map's element type, then store it under map[bool]T{true: value}. This covers query, path, and header parameters in addition to forms.
• bindFormImpl (bindform.go): a bool-keyed map field recurses through bindFormImpl on the element type and wraps the result, so Nullable[ComplexStruct] works alongside scalars. A non-bool-keyed map field routes to a new bindFormMap helper that binds entries of the form name[key]=value into a generic map[K]V.

The structural map[bool]T check keeps runtime decoupled from github.com/oapi-codegen/nullable; the data shape is the whole type, so detecting it by reflection is equivalent to importing the package.

An absent form field still produces an unspecified (zero) Nullable, matching the pre-fix behavior. Form payloads have no way to encode an explicit null, so name= binds as the inner type's zero value (specified), symmetric with non-nullable form binding.

Tests cover scalar Nullable, generic map[K]V, and the absent-field-stays-unspecified path.

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	github.com/​oapi-codegen/​nullable@​v1.1.0

View full report