Oops, I sent that before I finished editing it. I meant struct StrSlice
{start: &u8, length: uint}
On Tue, Mar 25, 2014 at 4:33 PM, Phil Dawes <rustp...@phildawes.net> wrote:
> Thanks Huon, that really cleared things up for me.
>
> Dum question: What's the reason for &str being a special fat pointer as a
> language feature rather than just a vanilla struct? E.g. struct StrSlice<T>
> {start: &T, length: uint}
>
> (I suppose this question also applies to &[T])
>
>
>
> On Mon, Mar 24, 2014 at 8:06 AM, Huon Wilson <dbau...@gmail.com> wrote:
>
>> It would be necessary (but not sufficient*) for them to have the same
>> in-memory representation, and currently ~str and &str don't.
>>
>> ~str is `*{ length: uint, capacity: uint, data... }`, a pointer to a
>> vector with the length and capacity stored inline, i.e. one word; &str is
>> just `{ data: *u8, length: uint }`, a pointer to a chunk of memory along
>> with the length of that chunk, i.e. two words.
>>
>>
>> (*E.g. std::cell::Cell<uint> and uint have the same in-memory
>> representation, but coercing a &[uint] to a &[Cell<uint>] is a very bad
>> idea... when it would theoretically be possible relates to subtyping/type
>> variance.)
>>
>> Huon
>>
>>
>> On 24/03/14 17:36, Phil Dawes wrote:
>>
>> To complete my understanding: is there a reason a 'sufficiently smart
>> compiler' in the future couldn't do this conversion implicitly?
>>
>> I.e. if a function takes a borrowed reference to a container of
>> pointers, could the compiler ignore what type of pointers they are (because
>> they won't be going out of scope)?
>>
>> Thanks,
>>
>> Phil
>>
>>
>> On Sun, Mar 23, 2014 at 7:14 AM, Patrick Walton <pcwal...@mozilla.com>wrote:
>>
>>> On 3/23/14 12:11 AM, Phil Dawes wrote:
>>>
>>>> On Sun, Mar 23, 2014 at 2:04 AM, Patrick Walton <pcwal...@mozilla.com
>>>> <mailto:pcwal...@mozilla.com>> wrote:
>>>>
>>>> Why not change the signature of `search_crate` to take `~str`?
>>>>
>>>> Patrick
>>>>
>>>>
>>>> Hi Patrick,
>>>>
>>>> The main reason I haven't done this is that it is already used from a
>>>> bunch of places where a path is &[&str] as the result of an earlier
>>>> split_str("::")
>>>> e.g.
>>>> let path : ~[&str] = s.split_str("::").collect();
>>>> ...
>>>> search_crate(path);
>>>>
>>>
>>> Ah, I see. Well, in that case you can make a trait (say, `String`),
>>> which implements a method `.as_str()` that returns an `&str`, and have that
>>> trait implemented by both `&str` and `~str`. (IIRC the standard library may
>>> have such a trait already, for `Path`?)
>>>
>>> You can then write:
>>>
>>> fn search_crate<T:String>(x: &[T]) {
>>> ...
>>> for string in x.iter() {
>>> ... string.as_str() ...
>>> }
>>> }
>>>
>>> And the function will be callable with both `&str` and `~str`. Again, I
>>> think the standard library has such a trait implemented already, for this
>>> use case.
>>>
>>> Patrick
>>>
>>>
>>
>>
>> _______________________________________________
>> Rust-dev mailing
>> listRust-dev@mozilla.orghttps://mail.mozilla.org/listinfo/rust-dev
>>
>>
>>
>> _______________________________________________
>> Rust-dev mailing list
>> Rust-dev@mozilla.org
>> https://mail.mozilla.org/listinfo/rust-dev
>>
>>
>
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
