Skip to content

AsciiStr and AsciiString APIs should be similar to str and String APIs #13

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

Open
osa1 opened this issue Jan 1, 2016 · 5 comments
Open
Assignees

Comments

@osa1
Copy link

osa1 commented Jan 1, 2016

Ideally the APIs should be the same, except the UTF-related bits (like str's utf16_units) and porting programs should be very easy. Currently lots of methods are missing in AsciiStr and AsciiString. (like str.lines(), str.bytes(). str.parse() ...)

@tormol
Copy link
Collaborator

tormol commented Aug 19, 2016

Is there any work in progress here or can I work on this?

@tomprogrammer
Copy link
Owner

I did some work already and got stuck at the implementation of the custom iterators. I'm currently not at home and will push a new branch soon.

@tormol
Copy link
Collaborator

tormol commented Dec 23, 2016

What should be done with methods with "str" in the name?
It can refer both to ASCII str and UTF-8 str, but specifying breaks the API, and we might want both for interoperability.

From into_boxed_str() and from_boxed_str() we want to return Box<AsciiStr>/AsciiString, but from FromStrs from_str() we don't have a choice but to return str.
And then there is AsciiString::as_str() which could return either.

@tomprogrammer
Copy link
Owner

The most methods returning an ascii string already use the ascii_str suffix, for example AsciiStr::to_ascii_string(). It also applies to all conversion traits, which return ascii strings (AsAsciiStr::as_ascii_str()). If the suffix is only str, like AsciiStr::as_str(), a UTF-8 string slice is returned.

I would like to follow this naming convention because it explicitly states whether the method works on ascii strings or UTF-8 strings.

That means the existing AsciiString::push_str() should be changed to AsciiString::push_ascii_str(). Of course that breaks the one-to-one mapping of the methods from String to AsciiString, but is it really that important? Changing these method calls should be fairly easy.

Using the example AsciiString::push_str() I see an ambiguity. Should this method take a str, push it onto the AsciiString and return a Result<AsciiString, FromAsciiError<Self>> or rather return a String? Mixing strings of different encoding should be handled by converting them into a common type before pushing, like ascii_string.push_ascii_str(string.as_ascii_str()?) or ascii_string.into_string().push_str(string).

I would call the methods into_boxed_ascii_str() and from_boxed_ascii_str() if they return Box<AsciiStr> or AsciiString. A method called into_boxed_str() should return Box<str> following the naming convention.

What do you think about it?

@PatrickNorton
Copy link
Contributor

On a similar note, could we get Arc::<AsciiStr>::from(AsciiString) to mirror Arc::<str>::from(String)?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants