[rust-dev] strings, slices and nulls

Brian Anderson banderson at mozilla.com
Wed Apr 18 13:54:58 PDT 2012


On 04/18/2012 01:51 PM, Brian Anderson wrote:
> On 04/18/2012 12:43 PM, Niko Matsakis wrote:
>> On 4/18/12 12:17 PM, Brian Anderson wrote:
>>> I would kind of like for Rust strings not to expose the fact that they
>>> are null-terminated (or just not be null terminated) but it seems
>>> unavoidable.
>>
>> +1
>>
>> I can see the practicality of null-terminating, but I would really like
>> to preserve the flexibility to reverse that decision in the future.
>> Forcing people to go through str::as_bytes() to observe the null
>> terminating seems like a win—except that I'd probably call it as_cstr()
>> or something like that, to emphasize it's null-terminated-ness.
>>
>>
>
> I was considering that the behavior of as_bytes is a little surprising
> because it exposes the null-terminator. We also already have as_c_str,
> which is built off of as_bytes. (Also we have as_buf). Ideally only
> as_c_str exposes the null-terminater, but if that's the case then
> there's no reason for as_bytes or as_buf and you should just use
> str::bytes to get a fresh, non-null-terminated copy. They are all just
> doing an unsafe cast so exposing the implementation is unavoidable.

As I think about this further, with slices we probably don't need as_buf 
or as_bytes since I think we will be able to create a string slice from 
a vec slice and vice versa.


More information about the Rust-dev mailing list