-
Notifications
You must be signed in to change notification settings - Fork 18k
x/text/encoding/ianaindex: implement package #18278
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Labels
Milestone
Comments
I'd like to see it kept and implemented, but I don't have much free time right now, and @mpvl is on long-term leave. |
CL https://golang.org/cl/34530 mentions this issue. |
gopherbot
pushed a commit
to golang/text
that referenced
this issue
Dec 16, 2016
Updates golang/go#18278 Change-Id: I1713bff63db5e68e074043f8f34c4998a4ab1275 Reviewed-on: https://go-review.googlesource.com/34530 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Nigel did option 1. Eventually we will implement the package. |
CL https://golang.org/cl/36515 mentions this issue. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
The ianaindex package was added back in April 2015 (CL 8393 by @mpvl) as a proposed API, but was never actually implemented. Calling any method in the package leads to a panic.
The current state of the package is not documented and it is not clear to possible users that the package is basically just a proposal and not usable. Most users will only find out when running the code or by reading the code.
This is very unfortunate, especially since there is currently no (documented) way to get the names of all encodings in the golang.org/x/text/encoding sub-packages. Users who want to get encodings by name or vice versa must currently resort to asserting and calling the (undocumented) String() method on the encodings and building the mappings themself. This still doesn't completely solve the problem since the String() method on the encodings doesn't return the MIME or IANA name of the encodings (and can't return both).
I think the current situation is the worst case for the package and a decision should be taken. I've listed the 3 possible actions/solutions that can be taken (and that I can currently think of) below.
Updating the documentation to note the current state
This is not a solution, but could be used as temporary solution before making a final decision on the future of the package.
Finalizing and implementing the package API
This is probably the best solution for users of the golang.org/x/text/encoding packages, but means that someone would have to implement and maintain the API.
The proposal is currently incomplete (there is a TODO about a Set method in there, as well as a few TODOs and a NOTE below the imports) and should probably revised (maybe with a new issue for the API design).
Removing the package
This solution has the obvious drawback that users can't get encodings by name or vice versa, at least not through the public API. Considering the current state of the package, this wouldn't remove any usable functionality or impact an other packages or applications (if it does, I want to see the code that uses it).
Basically I see it as coming down to the question of whether the package should be kept and implemented or deleted.
/cc @nigeltao (as reviewer of the original CL)
The text was updated successfully, but these errors were encountered: