Hacker News Reader

Comment by adkadskhj | Hacker News Reader

Yea but i don't think that's what GP was asking, imo. Rather than `[str]`, i think they were asking why it's `str` and not `[char]`, no?

Just as `[u8]` is to `Vec<u8>`, `[char]` is hypothetically to `Vec<char>`.. and `Vec<char>` is basically a `String`, no?

_edit_: Though looking at the docs, `char` is 4 always bytes, so i guess that's where the breakdown would be? `char` would need to be unsized i guess, but then it would be an awkward `[unsized_char]`, which is like two unsized types.... hence `str` maybe?

View on HN

`char` is a (internally) a `u32` because it represents any single unicode character. `str` is not a `[char]`, because rust doesn't store strings as utf-32 (system APIs don't accept utf-32, and it tends to waste space in many cases)

`str`'s data layout happens to be `[u8]`, but it's type provides additional guarantees about the structure of the data within it's internal `[u8]` (for example, forbidding sequences of u8 that don't encode valid utf-8).

To be extra pedantic, char represents a single Unicode Scalar Value.

This is a big deal because adding an accent mark to a letter (often) means a single char can no longer store it. APIs should not orient around isolated scalar values or codepoints because most devs will misuse them, not being experts on combining and normalization.

Well yea, i wasn't saying `[char]` _is_ a `str`, rather i was positing that the GP comment was asking why it's a `str` than some hypothetical `[unsized_char]`.

I think `char` _would_ work, if it was similarly unsized like a single piece of `str`. The Problem is .. as i see it, that `[unsized_char]` seems odd.

Yes, the reason you can't use char here is that a char is always 4 bytes, so a &[char] is a type that already exists, and that type uses four bytes per character.

`str` is not `[char]`, there is no datatype `char` possible or which this would hold, and the name is already taken.

`str` is not a slice; this is itself already a wrong statement. A slice is a dynamically sized type, a region of memory that contains any nonnegative number of elements of another type.

A `str` is dynamically sized, but is not guaranteed to contain a succession of any particular type. It's simply a dynamically sized sequence of bytes guaranteed to be Utf8.

`strs` aren't slices; all they have in common with them is that they are both dynamically sized types.

`Vec<char>` is also not the same as `String`; a string is not a vector of `char`, which is already a type that has a size of 4 bytes.

This all results from that Utf8 is a variable width encoding, and since slices are homogeneous, all elements have the same size.

Reply on news.ycombinator.com