proposal: x/text: expose MIBenum via identifier package

[rykov]

I am having trouble finding a way to store and look-up a specific encoding by MIBenum. It would be much more convenient and compact to have access to the MIBenum, rather than using a string name. I would like to start a discussion about exposing MIBenum via the ID() method for Encoding by moving identifier.Interface, identifier.MIB, out of an internal package, as well as exposing FindMIB for ianaindex.Index.

MIB enum is part of the IANA standard as described here:
https://www.iana.org/assignments/character-sets/character-sets.xhtml

[ianlancetaylor]

CC @mpvl

[rsc]

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

[rsc]

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

[rykov]

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.

[rsc]

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

[rsc]

ping @rykov; what API are you suggesting?

[rykov]

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

[rsc]

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).

[rykov]

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

[rsc]

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?

[rykov]

@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?

[rsc]

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.

[rykov]

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.