Pass `&` references by value

[rkjnsn]

when allocation is not available, Vec cannot be used.

I don’t follow this. The only operations that require allocation or access to “capacity” are ones that modify the Vec, but you can’t do those with a &Vec, anyway. You can still read and iterate through the elements, and even clone the Vec if you need a mutable copy.

Unless you mean Vec couldn’t be made Copy, but it wouldn’t have to be. The only restriction would be that it could not contain internal mutability (no Unsafe elements, as tbu mentioned), which it doesn’t.

[rkjnsn]

How would Vec and String operations that return a view into the object be implemented with your proposal?

[noamraph]

@P1start You are right that the idea can be separated into two proposals, but I don’t think they are unrelated. The second, for dropping the special types &str and &[T]` requires the first, and I think it makes the first idea very compelling.

As @tbu and @rkjnsn noted, there’s no need for Copy, the only requirement is that there won’t be any Unsafe elements.

As @rkjnsn said, I don’t think there’s a problem with using &Vec and &String in code without allocation. String and Vec could be defined in core, along with the operations on &Vec and &String which don’t require allocation. Methods which create a new Vec or String, which require allocation, would be defined in std, where allocation is available.

@rkjnsn Operations that return a view into an object could be implemented just like they are implemented now, using mem::transmute. For example, the current implementation of Vec<T>::as_slice is:

fn as_slice<'a>(&'a self) -> &'a [T] {
    unsafe { mem::transmute(Slice { data=self.as_ptr(), len=self.len }) }
}

If my proposal is accepted, you’d just need to replace &'a [T] with &Vec<'a, T> and it would work.

[P1start]

I still don’t see why the first proposal is necessary for the second. Right now &str is represented as (ptr, len). With your second proposal, &String is represented as str where str points to (ptr, len). Sure, this is less efficient, but I don’t think it’s strictly required. And if the & optimisation is required, how do you handle &mut [T] with your system (because there is no such optimisation for &mut)? The #[not_in_view] optimisation also seems unnecessary (but obviously useful).

With those two additions (#[not_in_view] and by-value views/references), &String is now significantly different from String. It doesn’t have the capacity field, and it’s not actually a reference to a string as the name suggests. What you’ve effectively done is renamed &str to &String, which is both a good and a bad thing. Good: it’s less confusing—there is only one ‘base’ string type. Bad: it’s inconsistent—&String is basically just a String but without a capacity field, and when allocation is not available, String is not usable, while &String is. At the same time, you’ve added a new pointer type (or really, renamed one and added another), and Ref<'a, T> could easily turn out to be more common than the new &'a T and is counter-intuitive to what people expect (& is a reference (effectively a pointer AFAIK) in C++, and is used to construct a pointer in C/C++).

I can see the advantages, but I’m not sure they outweigh the disadvantages. It’s certainly a very interesting and original idea, though.

[noamraph]

I can see the advantages, but I’m not sure they outweigh the disadvantages. It’s certainly a very interesting and original idea, though.

Thanks! That’s very nice to hear!

I still don’t see why the first proposal is necessary for the second.

You are right that it’s not strictly required, but as Rust is a systems programming language, no one would agree to add an unneeded level of indirection just for the sake of consistency. So keeping the same performance is very important.

I haven’t thought about &mut [T]. I wonder how frequently it’s being used. Perhaps it can be replaced with a struct that contains a &mut T reference to the first element and a length? If it can’t, then my proposal doesn’t handle &mut [T]. Too bad!

you’ve added a new pointer type (or really, renamed one and added another), and Ref<'a, T> could easily turn out to be more common than the new &'a T and is counter-intuitive to what people expect

I have dropped my idea about Ref<'a, T>, to avoid extra complexity in the language. So now &Foo would always be a view of Foo, and would always behave the same way, but may be implemented either as a value copy or as a pointer, according to the type attributes. I agree that it would make the implementation more opaque than it is today. It can be seen as an optimization - think about &Foo as a pointer to Foo, and if the author of the library thought that it would be more efficient to pass it by copying the bytes, it would work that way.

it’s inconsistent—&String is basically just a String but without a capacity field, and when allocation is not available, String is not usable, while &String is.

I don’t see &String and String as inconsistent. According to my proposal, &String would have just the same functionality as &String has now - you won’t be able to distinguish between the two without size_of. It’s just an optimization - if you are not allowed to mutate the object, you have no interest in the capacity, so there’s no need to copy it.

Edit: Currently Vec has a method pub fn capacity(&self) -> uint, which would of course not work with my proposal. From what I can see, it could be replaced by pub fn capacity(&mut self) -> uint without causing any trouble.

[rkjnsn]

First, the explanation. Every type Foo has its size_of<Foo>() bytes. Unless some of them are of type Unsafe (usually they aren’t), whenever a view &foo is alive, the compiler makes sure that those bytes are not mutated. If they are not mutated, it means that it doesn’t matter whether you have a pointer to those bytes, or if you have a copy of those bytes. This means that the question of whether the type &Foo is a pointer or a copy of Foo's bytes is just an implementation detail.

@rkjnsn Operations that return a view into an object could be implemented just like they are implemented now, using mem::transmute. For example, the current implementation of Vec<T>::as_slice is:

fn as_slice<'a>(&'a self) -> &'a [T] {
    unsafe { mem::transmute(Slice { data=self.as_ptr(), len=self.len }) }
}

If my proposal is accepted, you’d just need to replace &'a [T] with &Vec<'a, T> and it would work.

This seems somewhat contradictory to me. If the library implementation has to rely on &Vec<'a, T> having a specific layout, then passing & references by value becomes more than just an implementation detail. It is, in effect, another type. I think this has the potential to be confusing, and the possibility of having two &Vec<'a, T>s that point to the same vector and yet are not equal (one being a slice) is semantically weird. I also don’t like the idea that the semantic meaning of &Type depends on a attribute on Type

All that said, I do like the idea of the compiler being able to automatically pass small-enough & references by value as an optimization for types without Unsafe. Is there currently anything in the language definition that would prevent a conforming compiler from doing this, today?

[system]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.