In the rust docs, the slice type [T] is defined as a dynamically sized "view" into a contiguous sequence of elements (of any type T), so is string slice (str) just a specific version of the slice type or is it its own thing? I am confused cuz it is a primitive type too, isn't it just [u8]?
In the rust docs, str is called a string slice, so is it just a view of an owned UTF-8 data?
you can read the source code mang
You could see str as a wrapper around [u8] that guarantees its contents are UTF-8. (It's not actually a wrapper but AFAIK that's basically an implementation detail and it could be implemented as a wrapper today.)It behaves a lot like slice types but it doesn't have the same interface. For example you can only slice it (&text[10..15]), not index it (text[10]), and if you slice it such that you'd cut a UTF-8 scalar value in half you get a panic.
&text[10..15]
text[10]
>>109708874No, str is guaranteed to be valid unicode[u8] is not.
>>109708874str and [T] are separate primitive types in the sense that a str is a data view of valid UTF-8 sequence, so it is similar to [u8] but not the same, both are also dynamically sized so can only be used through pointer types.>>109708895the reason you can't index string types in rust is cuz UTF-8 is variable length, ASCII characters are all byte long but other characters aren't, so indexing can be ambiguous.
i wish you the best of on your gender transitions, but i am sticking with java (also MemorySafe™)
>>109708874str has the same layout as [u8], the only difference is that str guarantees that the underlying bytes are valid utf8.don't listen to the other posters here, they are clueless.
>>109709182>so indexing can be ambiguous.indexing could have been char-based. making it byte-based was an interface choice.
>>109709480Codepoint-based offsets wouldn't have been feasible without either making indexing O(n) or changing a bunch of other stuff
>>109709480wrong, you the Index trait returns references, since str is bytes underneath you can't return a reference to a char.>>109709484wrong
>>109709732>wrongCan you elaborate? How would you do codepoint-based offsets in less than O(n) without changing the data representation?
>>109709484and that was the choice.>since str is bytes underneath you can't return a reference to a char.both u8 and char are Copy. for range indexing, you would still return &str based on byte offsets of chars.
>>109710143second part was directed at >>109709732 obviously
>>109710143https://doc.rust-lang.org/stable/std/ops/trait.Index.html#tymethod.index>fn index(&self, index: Idx) -> &Self::Output>&Self::Output
what is the difference between str and &str?
>>109710284str is a dynamically sized typehttps://doc.rust-lang.org/reference/dynamically-sized-types.html#dynamically-sized-types
>>109708874str is a view into contiguous sequence of valid utf-8 data.>>109709480str is not char based. char is an unicode code point stored as a 32 bit integer. UTF-8 uses 8 bit code unit arranged in an variable length encoding. There is no UTF-8 encoded character primitive so indexing str doesn't make sense. Making a subslices like &text[start..end] does make sense because utf-8 slices(&str) do exist.If you want to access 10th character, just do text.chars().nth(10). If you want to access 10th byte do text.bytes().nth(10).
>>109710375very ESL coded post, but correct
>>109710284&str is just a borrow or str (string slice), you cannot directly use str because its size isn't known at compile time.
>>109710391>you cannot directly use strwrong
>>109710284str is the unsized slice of memory, just like [u8]. You can't put it in a variable because variables must have fixed footprint on stack, but you can put it in a Box for example.&str is a reference to that slice. It is represented as a fat pointer, ie an address and length of that slice of memory it refers to.Most of the time you will be manipulating &str because they are just pointers instead of the actual data of an arbitrary size.
>>109710401I meant you cannot directly assign str type to some variable.>>109710405box is another pointer type like a reference, you can use slice types only through pointers
>>109710459Depends on what you mean by use. You can reason about str on the type level, make a PhantomData of them, etc. You just can't put them directly on stack.
>>109710496Also you can put them as a trailing end of a DST struct.struct SuperStr { header: u32, data: str,}
struct SuperStr { header: u32, data: str,}
>>109710171not the point.Index<usize> can return &str of the single char bytes. or more appropriately, a wrapper with `.get() -> char` (like NonZero).byte indexing was an interface choice, period.>>109710375irrelevant quibble
>>109710805>Index<usize> can return &str of the single char bytesUsecase?
that's what you get for using data types other than *char
>>109710805>Index<usize> can return &strthat's retarded thoughor more appropriately, a wrapper with `.get() -> char`string.chars().nth(index)>byte indexing was an interface choiceno, the index trait is limited to returning references
>>109710818it's char * retard
>>109710809zero chance of panic when indexing in-range.in this imaginary pre rust v1.0 world, str::len() is char based too, of course (and you would find a way to return char anyway). but that interface was "not picked", which is not the same as "not possible".a third way, which would probably have been best is to always explicitly access via either a byte view or a char view. but the "ergonomic <=> shorter" trap was probably too strong.
>>109710891don't make me *kick your ass *
PRAISE THE SUN \[T]/
>>109710910please rewrite your post in english
>>109710910>zero chance of panic when indexing in-range.There is zero chance of that anyway because no one ever needs "&str of the single char bytes". And these few who need it will find char_indicies() method more useful.Again, usecase of "&str of the single char bytes"?
>>109710858>no, the index trait is limited to returning referencesyou appear to be retarded.1. the interface choice was made pre Rust v1.0, where NO PART of the language was finalised yet.2. the reference doesn't have to be tied with `self`. it could be tied to a thread local, or self-addressed (value itself is stored as an address), or ...
>>109710910good morning saar!
>>109710979>the interface choice was made pre Rust v1.0source?>it could be tied to a thread local, or self-addressed (value itself is stored as an address), or ...dumb retard
>>109710979>thread localincredibly cnile coded
>>109710955>There is zero chance of that anywaypeople hit that panic all the time. they usually later wise up and use chars. then maybe wise up more and use unicode-segmentation and unicode-width, and maybe (depending on the use-case) wise up yet one more time and check up actual rendered width.but to say "there is zero chance of that anyway" shows your detachment from reality, possibly because you're a fizz-buzz expert. or maybe you just lack a command of basic logic.
why can't cniles understand that encoding of codepoints != codepoints != grapheme clusters?
>>109711042it's all bits m8
>>109711028>people hit that panic all the timeNot because they want "&str of the single char bytes". No one wants that.>but to say "there is zero chance of that anyway" shows your detachment from reality, possibly because you're a fizz-buzz expert. or maybe you just lack a command of basic logic.I have been programming in Rust for nearly a decade now. I made a game engine, two emulators, a web service and couple of less notable projects. There was only 1(one, uno) case where I needed "&str of the single char bytes", and that need was better accomplished by char_indicies() because it also comes with a char and is more flexible(iterator windows and such).Yeah, when I say that no one ever needs "&str of the single char bytes" I mean it.
>>109711049>what are types?
>>109711155 (checked)
>>109711157idk man, i thought the entire point was that they would tell me
>>109711169rustc does tell you
&str is just &[u8] with the guarantee that it's valid UTF8. You can transmute them into each other without issues. Same goes for String and Vev<u8>.
>>109711196>You can transmute them into each other without issueswrong
>>109708874in the same docs str is mentioned as a separate primitive type, its definition is in its name.
>>109711202 (me)actually I'm wrong, sorry
>>109711155the other side would argue that there are 0 cases (zero, zero) where you would want byte-level access, unless you're just treating str as Bstr anyway.and that byte access breaks the at-construction utf-8 validation, which is the whole point of the type.there is a reason why there was a faction which wanted that access to be at least marked unsafe somehow, which you should be aware of, if you're really a long time rustacean.
>>109708893Are you a stack overflow top contributor?
>>109711370>stackoverflowIt's obsolete now unc. It's for luddites
>>109711391That's not an answer to my question, you illiterate nigger.
>>109711363please rewrite your post in english
>>109711400Snailcat response
>>109711363>the other side would argue that there are 0 cases (zero, zero) where you would want byte-level access, unless you're just treating str as Bstr anyway.There are cases where you want byte oriented access. Not to read particular bytes of an utf-8 encoded string, that's not very useful. But if you want to make sure a string can fit in n bytes of space(eg when transmitting or saving it), you will want to know how long it is and where to truncate. This is where these panics often happen and it won't be solved by making "Index<usize> return &str of the single char bytes". It's by educating people about how utf-8 works and recommending *_char_boundary() methods. Making Index do useless thing that no one ever needs just because it won't panic is counterproductive. It will be more confusing than helpful.>there is a reason why there was a faction which wanted that access to be at least marked unsafe somehow, which you should be aware of, if you're really a long time rustacean.Nope
