CC @mpvl

In what context do you need to look up an encoding by MIBenum?

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

In what context do you need to look up an encoding by MIBenum?

@rsc Not so much for look-up, but rather for storage - storing a number is much more compact.

What is the exact API you are proposing? What packages would change and how?

ping @rykov; what API are you suggesting?

@rsc Sorry for the delay. I've prototyped the proposal in golang/text#30

The new API is

func (x *Index) FindMIB(mib identifier.MIB) (encoding.Encoding, error)

But identifier is an internal package. We would need to export MIB from some package (probably not all of identifier).

@rsc Right. I'm only exporting identifier.MIB and identifier.Interface as aliases, the rest stays internal.

It's very difficult to document those as aliases. We'd need to find some conversion back and forth to hide the existence of the internal package. Any ideas?

@rsc I don't fully understand: are you suggesting creating two separate types to wrap the internal ones, or do you think that moving the two types out of the internal package into the public package is the better way?

I looked some more at these packages. I think if we were going to add this API we would want to move x/text/encoding/internal/identifier to x/text/encoding/identifier first. I am not sure whether we should do that though.

I can try exposing a minimal API via x/text/encoding/identifier, and keep the rest hidden in x/text/encoding/internal/identifier or x/text/encoding/identifier/internal.

@mpvl and I talked about this. We spent a while trying to figure out where to define the MIB type, and we ended up back at "why is this necessary?" When I asked earlier the answer was "Not so much for look-up, but rather for storage - storing a number is much more compact." It seems like if you just need a mapping from name to compact form for storage, it would be easy to define a local one instead of reusing the MIB numbers, which suggests we shouldn't make any API changes here - the justification is not strong enough.

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

@rsc We've taken a different direction for text encoding in our project, so we no longer needs this feature. However, my 2¢: given that MIBenum is part of the standard, I disagree that the solution is to keep the mapping internal, and have a consumer of this library reimplement their own equivalent local mapping.

No change in consensus, so declined.
— rsc for the proposal review group