You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently we expose a public idna::uts46::Flags struct with only public fields, so adding another field is a breaking change. A new API design could make this more extensible, perhaps with a builder pattern.
Or on the contrary, should we make the idna::uts46 module private and only provide the configurationlessIDNA algorithms defined in the URL Standard? (Oops, domain to ASCII has gained a beStrict boolean parameter. Though maybe this one should be exposed as a separate domain_to_ascii_strict function?)
The text was updated successfully, but these errors were encountered:
Compare for example:
Currently we expose a public
idna::uts46::Flags
struct with only public fields, so adding another field is a breaking change. A new API design could make this more extensible, perhaps with a builder pattern.Or on the contrary, should we make the
idna::uts46
module private and only provide theconfigurationlessIDNA algorithms defined in the URL Standard? (Oops, domain to ASCII has gained abeStrict
boolean parameter. Though maybe this one should be exposed as a separatedomain_to_ascii_strict
function?)The text was updated successfully, but these errors were encountered: