cc @neild @ianlancetaylor

Updates: I added the Playground link and the pseudocode demonstrating the alternative approach.

Is this different than the following?

IDNA2000Lookup = idna.New(
  idna.MapForLookup(),
  idna.BidiRule(),
)

Is this different than the following?

IDNA2000Lookup = idna.New(
  idna.MapForLookup(),
  idna.BidiRule(),
)

Technically, it's the same. However, in terms of library user experience, it is quite different. I am confident in answering your question only because I have read through the entire file. I still remember that when I first checked the idna package I was very confused by the 10 different options where some seem to imply the others. For example, it was not clear to me that MapForLookup is a superset of ValidateLabels until I checked the source code. In fact, the documentation gave me the opposite impression that ValidateLabels could have done more than MapForLookup. It is also strange that I could not specifically turn off BidiRule.

A ready-to-use profile for IDNA2008 would save my past self lots of time, and this proposal is from the perspective of a new user of this library. I feel pre-defined profiles for common cases would encourage correct usage of the library and have values on their own even if, after knowing all the bits of this library, they could be defined in terms of current options. This is what I meant by "unintuitive" in my proposal. I would never know some combination is correct until I read the source code.

If I may, I really wanted to replace the Profile with bit flags and clearly define those composite options as bitwise-ors of other flags. However, I decided to maintain maximum backward compatibility in this proposal. If the maintainers of this library are in favor of such a radical reform (e.g., type Profile int), I will then agree that a user should be able to figure out the correct combinations by themselves with the new interface.

Perhaps we should put @neild's example explicitly into the docs?

Perhaps the docs should specify exactly how each profile is constructed.

// Lookup is the recommended profile for looking up domain names, according
// to Section 5 of RFC 5891. The exact configuration of this profile may
// change over time.
//
// The current configuration is equivalent to:
//   idna.NewProfile(
//     idna.MapForLookup(),
//     idna.BidiRule(),
//     idna.Transitional(true),
//   )
Lookup *Profile = lookup

Or we could change the var definition, at the expense of needing to initialize the profile at init time rather than statically:

Lookup = New(
  idna.MapForLookup(),
  idna.BidiRule(),
  idna.Transitional(true),
)

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

I have no strong opinion on whether we should add a predefined nontransitional lookup profile, but if we do I suggest NontransitionalLookup or LookupNontransitional as the name. IDNA2008Lookup isn't correct, because the idna package as a whole implements IDNA2008.

Perhaps the docs should specify exactly how each profile is constructed.

Thank you, I think I can be satisfied with this (especially after https://go-review.googlesource.com/c/text/+/317729/ is merged) because it clearly shows how I can create non-transitional versions of existing profiles. I am also happy with any of suggested names for the new profile (if we decide to add a new one).

It's unclear how #46001 will play out, but the fact that it's a question suggests that having the table available from an easy-to-call function (instead of having to copy an example) is probably worth doing.

(A function with an internal sync.Once seems better than a global var, to avoid init-time overhead for unused things.)

Looking at the definition of Profile, it has multiple methods we'd have to expose if we didn't expose the Profile itself.
And it only contains plain data, so we should be able to write a literal that the linker would drop if unused.
So exporting the Profile seems fine.

The docs for Lookup say it may change from time to time. Is it time to change it to non-transitional?
If we resolve that #46001 should change, then maybe we should implement that by changing idna.Lookup here?

We could still define idna.Transitional and idna.NonTransitional for people who want an explicit choice.

It's also unclear whether Display, Registration, and Punycode need to change at the same time.
Any ideas?

/cc @mpvl

The docs for Lookup say it may change from time to time. Is it time to change it to non-transitional?

If #46001 resolves in favor of using nontransitional processing in net/http, we should do that by changing idna.Lookup.

I do not believe Display, Registration, and Punycode need to change. Transitional processing only affects the lookup profile. (The docs for idna.Transitional state: "This option is only meaningful if combined with MapForLookup.")

OK, sounds like this is blocked on #46001.

#46001 is a likely accept, so I suppose this one is too (changing the default idna.Lookup).

Based on the discussion above, this proposal seems like a likely accept.
— rsc for the proposal review group

No change in consensus, so accepted. 🎉
This issue now tracks the work of implementing the proposal.
— rsc for the proposal review group

Change https://golang.org/cl/359634 mentions this issue: internal/export/idna: use nontransitional processing in Go 1.18

Change https://golang.org/cl/360381 mentions this issue: idna: update from x/text

N.B., this has been fixed in 77c473f for Go 1.18, which changes the pre-defined Lookup profile to be non-transitional.