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