internal/ascii: new internal package consolidating common functions

[apocelipes]

Proposal Details

The standard packages write their own ASCII helper functions many times, for examples you can find ASCII-only isSpace, toUpper and equalFold in "encoding/json", "net", "internal/filepathlite". The "net/http" also has a internal package called net/http/internal/ascii.

Handling ASCII-encoded characters is a common requirement in the standard library, so a new package can share these logic and eliminate duplicate codes.

Based on my investigation of the standard library code, the new package should have these functions in it:

• Is/IsString (check if it is ASCII)
• IsLower/IsUpper
• ToLower/ToUpper (for single char)
• ToLowerString/ToUpperString
• EqualFold
• IsSpace
• TrimSpace
• IsDigit
• IsLetter
• IsPrint

This package should minimize external dependencies, and some necessary constants can be copied from packages such as "unicode".

Normal users can continue to use "bytes", "strings" and "unicode" for most tasks, so there is little point in making this package public. However, many standard packages can't directly import packages like "unicode", "strings", etc., so I thought it would be appropriate to put this new package in "internal".

[ianlancetaylor]

Thanks. The proposal process is for externally visible changes, and this is a purely internal reorganization, so taking this out of the proposal process.

[ianlancetaylor]

The "lite" convention is for internal versions of packages that have a public API. So asciilite isn't the right name, since there is no ascii package. On the other hand, this could be internal/ascii.

[apocelipes]

The "lite" convention is for internal versions of packages that have a public API. So asciilite isn't the right name, since there is no ascii package. On the other hand, this could be internal/ascii.

Yes. internal/ascii is a suitable name.

[mitar]

Any reason why ascii.EqualFold would not be made public? In many protocols ASCII case-insensitive comparisons are present.

[jub0bs]

Another good candidate member of such a package: the asciiSet type, currently duplicated across packages strings and bytes.

[silverwind]

Normal users can continue to use "bytes", "strings" and "unicode" for most tasks, so there is little point in making this package public

I vote for making stuff like ascii.EqualFold part of the public API, because handling ASCII encoding is a common use case, for example when dealing with HTTP headers for which the only interoperable encoding is ASCII. The unicode behaviour of strings.EqualFold is not desirable there as it may even cause security vulnerabilities.