Re: [rust-dev] About owned pointer
Thanks for the clarification. The current design actually makes sense to me after re-reading about dynamically sized types. On Friday 08 November 2013 09:29:37 Patrick Walton wrote: On 11/8/13 7:47 AM, Diggory Hardy wrote: What's wrong with sticking with convention here? E.g. C++'s `string` and `vectorT` are objects containing two or three pointers. D's arrays and `string` act the same way. Even C's dynamic arrays (`int x[]`) can be thought of the same way (if one avoids thinking of them as pointers). Because: * We need slices in the language. They're important for soundness. * We need dynamically sized types in the language in order to be sound around first-class trait objects. * Given that we need slices, and we need dynamically-sized types, we can avoid introducing more concepts in the language by treating slices as just a special case of a dynamically-sized type. That is, a slice is nothing more than *a pointer to a dynamically-sized type*. * The pointer sigil is notated ``, and the dynamically-sized type is `[int]`. So the resulting notation is `[int]`. You can see slices as just pointers with a length attached; i.e. a pointer to multiple contiguous values. In fact, Cyclone called them fat pointers instead of slices. In Cyclone, you wrote a slice as `int *fat`. (Notice the similarity to `[int]`.) Note that not all of this is implemented today, which is leading to some of the confusion in this thread. Felix Klock is currently working on it. Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev signature.asc Description: This is a digitally signed message part. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
Just an humble opinion. I kind of like saying that the code i write must be beautiful. The langage should allow to write beautiful code. It is more than a personnal point of view, it is also very important. if it is a pain in the ... to use an essential feature, or if i will never remember how to do it without copy paste because there is no logic behind it, i will have a bad opinion on the langage itself. The real question are: - as a typicial rust programmer, will i see the usage of str or ~str as logic or will i have to copy paste some sample code each time because it works this way in rust - the boilder plates theory. Can i avoid them? I think a good modern language should allow me to avoid writing useless code, each time the same things. That is the real mess with C++. Gaetan Le samedi 9 novembre 2013, spir a écrit : On 11/09/2013 06:43 AM, Kevin Ballard wrote: On Nov 8, 2013, at 9:38 PM, Daniel Micay danielmi...@gmail.com wrote: On Sat, Nov 9, 2013 at 12:36 AM, Kevin Ballard ke...@sb.org wrote: On Nov 8, 2013, at 2:21 PM, Patrick Walton pcwal...@mozilla.com wrote: I know that many people don't like the fact that, syntactically, vectors and strings have a sigil in front of them, but please consider that there are many design constraints here. What works for another language may not work for Rust, because of these constraints. Personally, I find it great that they have a sigil in front of them. It reminds me that they're stored in the heap. -Kevin Since library containers, smart pointers and other types don't have them, I don't think it's helpful in that regard. Well no, you can't assume that the absence of a sigil means the absence of heap storage. But for types that are possibly not stored on the heap, such as str (which can be 'static str) and [T] (which can be a fixed-size stack-allocated vector), the ~ is a useful distinction. -Kevin Can we, then, even consider the opposite: having a sigil for static data (mainly literal strings stored in static mem, I'd say) or generally non-heap data (thus including eg static arrays stored on stack)? The advantage is that this restores coherence between all heap of heap data. I'd use '$'! (what else can this sign be good for, anyway? ;-) [But where should the sigil go? In front of the data literal, as in let stst = $Hello, world!; let nums = $[1,2,3]; or in front of the type, or of the id itself?] Also, is it at all possible, in the long term maybe, to consider letting the compiler choose where to store, in cases where a possible pointer is meaningless, that is it does not express a true reference (shared object, that a.x is also b.y), instead is used for technical or efficiency reasons (that memory is not elastic!, for avoiding copy, etc...)? Denis ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- - Gaetan ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On Mon, Nov 11, 2013 at 3:21 PM, Gaetan gae...@xeberon.net wrote: Just an humble opinion. I kind of like saying that the code i write must be beautiful. The langage should allow to write beautiful code. It is more than a personnal point of view, it is also very important. if it is a pain in the ... to use an essential feature, or if i will never remember how to do it without copy paste because there is no logic behind it, i will have a bad opinion on the langage itself. Of course, beauty is subjective. Personally, I see it as language-independent, and don't find it any harder to write beautiful code in Rust than in any other language I know. It's certainly easier than in some languages, since I don't have to spend as much time debugging run-time errors and can spend that time making my code aesthetically better. The real question are: - as a typicial rust programmer, will i see the usage of str or ~str as logic or will i have to copy paste some sample code each time because it works this way in rust Once you gain experience with Rust, this will seem natural. You reason about whether you're passing data by value or by reference (i.e. borrowed pointer) anyway, and Rust just makes that distinction more explicit. - the boilder plates theory. Can i avoid them? I think a good modern language should allow me to avoid writing useless code, each time the same things. That is the real mess with C++. I'm not sure what your question is here, sorry. Cheers, Tim Gaetan Le samedi 9 novembre 2013, spir a écrit : On 11/09/2013 06:43 AM, Kevin Ballard wrote: On Nov 8, 2013, at 9:38 PM, Daniel Micay danielmi...@gmail.com wrote: On Sat, Nov 9, 2013 at 12:36 AM, Kevin Ballard ke...@sb.org wrote: On Nov 8, 2013, at 2:21 PM, Patrick Walton pcwal...@mozilla.com wrote: I know that many people don't like the fact that, syntactically, vectors and strings have a sigil in front of them, but please consider that there are many design constraints here. What works for another language may not work for Rust, because of these constraints. Personally, I find it great that they have a sigil in front of them. It reminds me that they're stored in the heap. -Kevin Since library containers, smart pointers and other types don't have them, I don't think it's helpful in that regard. Well no, you can't assume that the absence of a sigil means the absence of heap storage. But for types that are possibly not stored on the heap, such as str (which can be 'static str) and [T] (which can be a fixed-size stack-allocated vector), the ~ is a useful distinction. -Kevin Can we, then, even consider the opposite: having a sigil for static data (mainly literal strings stored in static mem, I'd say) or generally non-heap data (thus including eg static arrays stored on stack)? The advantage is that this restores coherence between all heap of heap data. I'd use '$'! (what else can this sign be good for, anyway? ;-) [But where should the sigil go? In front of the data literal, as in let stst = $Hello, world!; let nums = $[1,2,3]; or in front of the type, or of the id itself?] Also, is it at all possible, in the long term maybe, to consider letting the compiler choose where to store, in cases where a possible pointer is meaningless, that is it does not express a true reference (shared object, that a.x is also b.y), instead is used for technical or efficiency reasons (that memory is not elastic!, for avoiding copy, etc...)? Denis ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- - Gaetan ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt If you are silent about your pain, they'll kill you and say you enjoyed it. -- Zora Neale Hurston ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On 12 Nov 2013, at 10:21 am, Gaetan gae...@xeberon.net wrote: - as a typicial rust programmer, will i see the usage of str or ~str as logic or will i have to copy paste some sample code each time because it works this way in rust” This is what I thought at first, but once you use it for a while it will become natural, and you will find the distinction very useful. Just give it a chance before you jump to conclusions - you won’t regret it! :) - the boilder plates theory. Can i avoid them? I think a good modern language should allow me to avoid writing useless code, each time the same things. That is the real mess with C++. They are not useless - `~str`, `str`, `'a str` and `'static str` all convey extremely important semantic information both to the programmer and to the compiler. Changing `~str` to `str` would cause more inconsistencies (what about the borrowed pointers?) with a loss of the afore mentioned semantic information. ~Brendan ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On 11/09/2013 06:43 AM, Kevin Ballard wrote: On Nov 8, 2013, at 9:38 PM, Daniel Micay danielmi...@gmail.com wrote: On Sat, Nov 9, 2013 at 12:36 AM, Kevin Ballard ke...@sb.org wrote: On Nov 8, 2013, at 2:21 PM, Patrick Walton pcwal...@mozilla.com wrote: I know that many people don't like the fact that, syntactically, vectors and strings have a sigil in front of them, but please consider that there are many design constraints here. What works for another language may not work for Rust, because of these constraints. Personally, I find it great that they have a sigil in front of them. It reminds me that they're stored in the heap. -Kevin Since library containers, smart pointers and other types don't have them, I don't think it's helpful in that regard. Well no, you can't assume that the absence of a sigil means the absence of heap storage. But for types that are possibly not stored on the heap, such as str (which can be 'static str) and [T] (which can be a fixed-size stack-allocated vector), the ~ is a useful distinction. -Kevin Can we, then, even consider the opposite: having a sigil for static data (mainly literal strings stored in static mem, I'd say) or generally non-heap data (thus including eg static arrays stored on stack)? The advantage is that this restores coherence between all heap of heap data. I'd use '$'! (what else can this sign be good for, anyway? ;-) [But where should the sigil go? In front of the data literal, as in let stst = $Hello, world!; let nums = $[1,2,3]; or in front of the type, or of the id itself?] Also, is it at all possible, in the long term maybe, to consider letting the compiler choose where to store, in cases where a possible pointer is meaningless, that is it does not express a true reference (shared object, that a.x is also b.y), instead is used for technical or efficiency reasons (that memory is not elastic!, for avoiding copy, etc...)? Denis ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On Sat, Nov 09, 2013 at 09:46:38AM +1100, Huon Wilson wrote: Ah, of course. Presumably this means that `RcTrait` or `Rcstr` would require a separate code-path? I've been thinking about this somewhat. I'm not sure if this is true. And in fact while both `Trait` and `str` are dynamically sized types, they are not comparable and must be considered separately. 1. The type `Trait` is in fact not a type at all, it's shorthand for a type that the compiler forgot (jargon: an existential type). That is, every Every instance of `RcTrait` in fact began its life as a `RcT` for some known `T`, and the user cast away (pun intended) the `T` to make an object: RcT as RcTrait At runtime, this kind of cast (which, as an aside, I hope will no longer have to be explicit soon, it's quite tedious) pairs up the `RcT` with a vtable. So in fact `RcTrait` requires no participation on the part of `RcT`, but we will have to figure out some niggly details like how the compiler decides what type parameters can be changed from `T` to `Trait` and so forth. 2. True dynamically sized types like `[T]` and `str` are different, because they require fat pointers in place of thin ones. Until recently I was thinking we'd just (for now anyway) prohibit `Rc` and `Gc` etc from being instantiated with a DST. However, I was thinking recently that since `RcT` and `GcT` would build on `*T`, perhaps we can just define `*[T]` and `*str` to be the same sort of fat pointers, and things will work out rather nicely once everything is monomorphized. I have to think this over, but it's a promising idea. There are some complications for `Gc[T]`; when one traverses a pointer to this garbage-collected box, one must be sure to carry along the length information about the vector. But this doesn't seem unsolveable. Niko ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On Sat, Nov 09, 2013 at 09:43:45AM +1100, Huon Wilson wrote: This will make transmuting ~ to get a * (e.g., to allocate memory for storage in an Rc, with automatic clean-up by transmuting back to ~ on destruction) harder to get right, won't it? See my other e-mail about choosing a representation for `*T`. I am currently thinking that the representation of `~T`, `T`, and `*T` should be the same for all `T`. I think this addresses a number of issues and opens up new capabilities, though it does mean an unused capacity word for `[T]` and `*[T]`. See issue #10295. Anyway, I am not sure if I am making sense -- I'd say this calls for a long-winded blog post. Or more likely 2 or 3. I spent some time yesterday working out some of the details for supporting custom allocators as well as higher-kinded types, so I've got a lot to write about... Niko ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On 11/09/2013 08:36 PM, Niko Matsakis wrote: See my other e-mail about choosing a representation for `*T`. I am currently thinking that the representation of `~T`, `T`, and `*T` should be the same for all `T`. I think this addresses a number of issues and opens up new capabilities, though it does mean an unused capacity word for `[T]` and `*[T]`. See issue #10295. Well, you may need it in fact. When I did implement slices for a trial (more or inspired by and copying D), I used this free word as a flag (with value 0) saying that extension is not allowed: one cannot push items into or concatenate a slice. Otherwise, arrays and slices are the same kind of thing; and in my case, there was a single type, as in D, arrays just are original slices, slices are arrays, except one cannot extend them. The remaining issue is, as in D again, the case of an array, of which slices exist, that later gets extended: in the general case (where extension requires realloc elsewhere), this invalids slices. Reason why I ended up concluding slices should only exist for fix-size thingies; anyway it's the case in practice afaik, since slices are extensively used (and a huge efficiency gain) on strings mainly. The D design, as I see it, thus brings a low level of safety; but their goal, on this point, is not to reach a level as high as Rust aims, I guess. Would be happy to read your thoughts on such topics. Denis ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On Sat, Nov 9, 2013 at 8:53 AM, spir denis.s...@gmail.com wrote: Can we, then, even consider the opposite: having a sigil for static data (mainly literal strings stored in static mem, I'd say) or generally non-heap data (thus including eg static arrays stored on stack)? The advantage is that this restores coherence between all heap of heap data. I'd use '$'! (what else can this sign be good for, anyway? ;-) [But where should the sigil go? In front of the data literal, as in let stst = $Hello, world!; let nums = $[1,2,3]; or in front of the type, or of the id itself?] Also, is it at all possible, in the long term maybe, to consider letting the compiler choose where to store, in cases where a possible pointer is meaningless, that is it does not express a true reference (shared object, that a.x is also b.y), instead is used for technical or efficiency reasons (that memory is not elastic!, for avoiding copy, etc...)? Denis All variables in Rust are stack-allocated values. A unique pointer is a pointer stored on the stack, and may be defined as a library type. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
I agree, I don't understand the syntax here.
Look at the Url class:
pub struct Url {
scheme: ~str,
user: OptionUserInfo,
host: ~str,
port: Option~str,
path: ~str,
query: Query,
fragment: Option~str
}
pub type Query = ~[(~str, ~str)];
fn split_char_first(s: str, c: char) - (~str, ~str) {
...
if index+mat == len {
return (s.slice(0, index).to_owned(), ~);
}
}
Isn't simpler, and easier to read, if we write it
pub struct Url {
scheme: str,
user: OptionUserInfo,
host: str,
port: Optionstr,
path: str,
query: Query,
fragment: Optionstr
}
pub type Query = [(str, str)];
fn split_char_first(s: str, c: char) - (str, str) {
...
if index+mat == len {
return (s.slice(0, index).to_owned(), );
}
}
KISS !
-
Gaetan
2013/11/8 Jason Fager jfa...@gmail.com
Can you speak a little to the practical differences between owned boxes
and ~[T]/~str? How does the difference affect how I should use each?
On Thursday, November 7, 2013, Daniel Micay wrote:
On Thu, Nov 7, 2013 at 6:32 PM, Liigo Zhuang com.li...@gmail.com wrote:
Owned boxes shouldn't be commonly used. There's close to no reason to
use one for anything but a recursive data structure or in rare cases for an
owned trait object.
http://static.rust-lang.org/doc/master/tutorial.html#boxes
It's important to note that ~[T] and ~str are not owned boxes. They're
just sugar for dynamic arrays, and are common containers.
It's so confusing. If it's not owned box, why not remove ~? Make str
default be dynamic should OK.
It wouldn't be okay for every string literal to result in a heap
allocation.
___
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
Re: [rust-dev] About owned pointer
// An exchange heap (owned) stringlet exchange_crayons: ~str = ~Black, BlizzardBlue, Blue; can you clarify us? thx! - Gaetan 2013/11/8 Daniel Micay danielmi...@gmail.com On Thu, Nov 7, 2013 at 7:49 PM, Jason Fager jfa...@gmail.com wrote: Can you speak a little to the practical differences between owned boxes and ~[T]/~str? How does the difference affect how I should use each? I wrote the section on owned boxes in the tutorial currently in master, so I would suggest reading that. It's very rare for there to be a use case for an owned box outside of a recursive data structure or plugin system (traits as objects). The coverage in the tutorial of vectors/strings is not only lacking in depth but is also *incorrect*, so I understand why there's a lot of confusion about them. Vectors/strings are containers, and aren't connected to owned boxes any more than HashMap/TreeMap/TrieMap. I would prefer it if the syntactic sugar didn't exist and we just had generic container literals, because it seems to end up causing a lot of confusion. ___ 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
Re: [rust-dev] About owned pointer
On Fri, Nov 8, 2013 at 3:43 AM, Gaetan gae...@xeberon.net wrote:
I agree, I don't understand the syntax here.
Look at the Url class:
pub struct Url {
scheme: ~str,
user: OptionUserInfo,
host: ~str,
port: Option~str,
path: ~str,
query: Query,
fragment: Option~str
}
pub type Query = ~[(~str, ~str)];
fn split_char_first(s: str, c: char) - (~str, ~str) {
...
if index+mat == len {
return (s.slice(0, index).to_owned(), ~);
}
}
Isn't simpler, and easier to read, if we write it
pub struct Url {
scheme: str,
user: OptionUserInfo,
host: str,
port: Optionstr,
path: str,
query: Query,
fragment: Optionstr
}
pub type Query = [(str, str)];
fn split_char_first(s: str, c: char) - (str, str) {
...
if index+mat == len {
return (s.slice(0, index).to_owned(), );
}
}
KISS !
It couldn't be called `str`, because `str` is a slice.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On Fri, Nov 8, 2013 at 3:46 AM, Gaetan gae...@xeberon.net wrote: // An exchange heap (owned) stringlet exchange_crayons: ~str = ~Black, BlizzardBlue, Blue; can you clarify us? thx! - Gaetan I suggest ignoring the string/vector section in the tutorial because it's misleading and in some places incorrect. I'll send in a pull request removing the incorrect information. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
I think a clear paragraph on these cases (~ and ~[]) will help a lot the understanding of this subtlety... - Gaetan 2013/11/8 Daniel Micay danielmi...@gmail.com On Fri, Nov 8, 2013 at 3:46 AM, Gaetan gae...@xeberon.net wrote: // An exchange heap (owned) stringlet exchange_crayons: ~str = ~Black, BlizzardBlue, Blue; can you clarify us? thx! - Gaetan I suggest ignoring the string/vector section in the tutorial because it's misleading and in some places incorrect. I'll send in a pull request removing the incorrect information. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On Fri, Nov 8, 2013 at 4:05 AM, Gaetan gae...@xeberon.net wrote: I think a clear paragraph on these cases (~ and ~[]) will help a lot the understanding of this subtlety... - Gaetan Here are the changes: https://github.com/mozilla/rust/pull/10354 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On Thu, Nov 07, 2013 at 04:48:06PM -0500, Daniel Micay wrote:
Owned boxes shouldn't be commonly used. There's close to no reason to use
one for anything but a recursive data structure or in rare cases for an
owned trait object.
I don't really agree with this statement. I agree that those are the
two cases an owned pointer is mandatory, and that the choice between
`T` and `~T` is a matter of optimization, and hence something that
should be measured.
However, I don't think it's *so* unusual that one might want
pointer-sized values. Off the top of my head, here are some more
scenarios where owned pointers certainly make sense:
1. Options, particularly those that are frequently none.
`Option~HashMap...` is a single word in size. If it is
`None`, that's just a NULL pointer.
2. Enum variants. The size of an enum is the size of its largest
variant. If you have:
enum Foo {
Opt1(uint),
Opt2(HashMap...),
Opt3(uint, uint, uint),
}
You are potentially wasting a lot of space, unless `Opt1` is very
rare. You'd be better off doing something like:
enum Foo {
Opt1(uint),
Opt2(~HashMap...),
Opt3(~Opt3)
}
struct Opt3 { uint, uint, uint }
Niko
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On Fri, Nov 08, 2013 at 07:32:02AM +0800, Liigo Zhuang wrote: It's so confusing. If it's not owned box, why not remove ~? Make str default be dynamic should OK. I am not sure why Daniel says that a `~str` or `~[]` is not an owned box. I guess he's using the term in some specific way. I consider `~str` and `~[]` to be exactly the same as any other `~T` value in usage and semantics. They are allocated on the same heap, moved from place to place, and freed at the same time, etc. The difference between a type like `str` or `[T]` and other types is that `str` and `[T]` are actually a series of values: `u8` bytes and `T` values respectively. This entails a change in representation and is also the reason that one *must* use a pointer to refer to them, because the number of values is not known and hence the compiler can't calculate the size of the value. Note that we are to some extent evolving how we handle dynamically sized types like `str` and `[]`. Right now they are quite second class (you can't impl them etc) but that will change. Nonetheless, it will remain true that you can never have a *value* of type `str` or `[]`, but most always use a pointer (either `~[]` or `[]`). Also note that a type like `~[T]` is in fact going to be represented not as a single pointer but rather three pointers, thanks to work by Daniel in fact. Niko ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On Thu, Nov 07, 2013 at 08:40:27PM -0500, Jason Fager wrote: Let me ask another way: what's wrong with thinking of ~ just as meaning allocate to the heap and subject to move semantics? When would that simplification bite me in the ass regarding owned boxes vs strs/vecs? I don't consider that to be a simplification, really. It sounds about right to me. Of course a `~` pointer is not the only way to have move semantics; any destructor will do. Niko ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On Fri, Nov 8, 2013 at 6:24 AM, Niko Matsakis n...@alum.mit.edu wrote:
On Thu, Nov 07, 2013 at 04:48:06PM -0500, Daniel Micay wrote:
Owned boxes shouldn't be commonly used. There's close to no reason to use
one for anything but a recursive data structure or in rare cases for an
owned trait object.
I don't really agree with this statement. I agree that those are the
two cases an owned pointer is mandatory, and that the choice between
`T` and `~T` is a matter of optimization, and hence something that
should be measured.
However, I don't think it's *so* unusual that one might want
pointer-sized values. Off the top of my head, here are some more
scenarios where owned pointers certainly make sense:
1. Options, particularly those that are frequently none.
`Option~HashMap...` is a single word in size. If it is
`None`, that's just a NULL pointer.
2. Enum variants. The size of an enum is the size of its largest
variant. If you have:
enum Foo {
Opt1(uint),
Opt2(HashMap...),
Opt3(uint, uint, uint),
}
You are potentially wasting a lot of space, unless `Opt1` is very
rare. You'd be better off doing something like:
enum Foo {
Opt1(uint),
Opt2(~HashMap...),
Opt3(~Opt3)
}
struct Opt3 { uint, uint, uint }
Niko
I don't think the need to do micro-optimizations like this is *common*
though. It gets to the point where you're optimizing for the
characteristics of a specific allocator because they use different size
class buckets so trusting a profiler on one platform isn't enough.
There's a very real cost to the indirection, extra pointers in the CPU
cache, and all the landing pad stuff that ends up generated. I don't deny
that indirection can be useful for optimization, but it's unintuitive and
often not a portable improvement.
In the Boxes section I wrote for the tutorial, it includes this:
In uncommon cases, the indirection can provide a performance gain or
memory reduction by making values smaller. However, unboxed values should
almost always be preferred.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On Fri, Nov 8, 2013 at 6:33 AM, Niko Matsakis n...@alum.mit.edu wrote:
On Fri, Nov 08, 2013 at 07:32:02AM +0800, Liigo Zhuang wrote:
It's so confusing. If it's not owned box, why not remove ~? Make str
default be dynamic should OK.
I am not sure why Daniel says that a `~str` or `~[]` is not an owned
box. I guess he's using the term in some specific way. I consider
`~str` and `~[]` to be exactly the same as any other `~T` value in
usage and semantics. They are allocated on the same heap, moved from
place to place, and freed at the same time, etc.
The difference between a type like `str` or `[T]` and other types is
that `str` and `[T]` are actually a series of values: `u8` bytes and
`T` values respectively. This entails a change in representation and
is also the reason that one *must* use a pointer to refer to them,
because the number of values is not known and hence the compiler can't
calculate the size of the value.
Note that we are to some extent evolving how we handle dynamically
sized types like `str` and `[]`. Right now they are quite second class
(you can't impl them etc) but that will change. Nonetheless, it will
remain true that you can never have a *value* of type `str` or `[]`,
but most always use a pointer (either `~[]` or `[]`).
Also note that a type like `~[T]` is in fact going to be represented
not as a single pointer but rather three pointers, thanks to work by
Daniel in fact.
Niko
By owned box I just mean a type you can pass to `fn fooT(x: ~T) { }`
rather than something that's owned and has a heap allocation. Most of the
other containers (hashmap, treemap, trie, ringbuf, priority_queue) are also
owned, sendable and have a destructor.
In my opinion, it would be better to have stronger support for library
containers and only have vector/string slices built-in to the language.
Stronger support would entail generic container literals, overloading
auto-slicing and a rooting API for the GC (when we get one).
There are good reasons to write another vector type, such as allocator
support, optimizing for small vectors or ABI compatibility with a foreign
library's vector type to avoid copying between the API boundary.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On Fri, Nov 08, 2013 at 07:39:59AM -0500, Daniel Micay wrote:
By owned box I just mean a type you can pass to `fn fooT(x: ~T) { }`
rather than something that's owned and has a heap allocation.
Once the DST work is done, you will be able to pass a ~[T] to a
function like `fn fooT(x: ~T) { }`.
Niko
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On Friday 08 November 2013 06:33:23 Niko Matsakis wrote: I am not sure why Daniel says that a `~str` or `~[]` is not an owned box. I guess he's using the term in some specific way. I consider `~str` and `~[]` to be exactly the same as any other `~T` value in usage and semantics. They are allocated on the same heap, moved from place to place, and freed at the same time, etc. The difference between a type like `str` or `[T]` and other types is that `str` and `[T]` are actually a series of values: `u8` bytes and `T` values respectively. This entails a change in representation and is also the reason that one *must* use a pointer to refer to them, because the number of values is not known and hence the compiler can't calculate the size of the value. Note that we are to some extent evolving how we handle dynamically sized types like `str` and `[]`. Right now they are quite second class (you can't impl them etc) but that will change. Nonetheless, it will remain true that you can never have a *value* of type `str` or `[]`, but most always use a pointer (either `~[]` or `[]`). Also note that a type like `~[T]` is in fact going to be represented not as a single pointer but rather three pointers, thanks to work by Daniel in fact. What's wrong with sticking with convention here? E.g. C++'s `string` and `vectorT` are objects containing two or three pointers. D's arrays and `string` act the same way. Even C's dynamic arrays (`int x[]`) can be thought of the same way (if one avoids thinking of them as pointers). So why not consider `str` and `[T]` conglomerates of a fixed size containing the pointers (start, length and capacity or whatever) needed? Semantically it's the same while syntactically it's simpler. Slices will need new names of course, but I think the resulting decrease in confusion will be worth it. (D's developers tried to go the other way, with all arrays and slices being effectively copy-on-write slices, before realising that discrete array/slices types _were_ needed.) DH signature.asc Description: This is a digitally signed message part. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
I agree - Gaetan 2013/11/8 Diggory Hardy li...@dhardy.name On Friday 08 November 2013 06:33:23 Niko Matsakis wrote: I am not sure why Daniel says that a `~str` or `~[]` is not an owned box. I guess he's using the term in some specific way. I consider `~str` and `~[]` to be exactly the same as any other `~T` value in usage and semantics. They are allocated on the same heap, moved from place to place, and freed at the same time, etc. The difference between a type like `str` or `[T]` and other types is that `str` and `[T]` are actually a series of values: `u8` bytes and `T` values respectively. This entails a change in representation and is also the reason that one *must* use a pointer to refer to them, because the number of values is not known and hence the compiler can't calculate the size of the value. Note that we are to some extent evolving how we handle dynamically sized types like `str` and `[]`. Right now they are quite second class (you can't impl them etc) but that will change. Nonetheless, it will remain true that you can never have a *value* of type `str` or `[]`, but most always use a pointer (either `~[]` or `[]`). Also note that a type like `~[T]` is in fact going to be represented not as a single pointer but rather three pointers, thanks to work by Daniel in fact. What's wrong with sticking with convention here? E.g. C++'s `string` and `vectorT` are objects containing two or three pointers. D's arrays and `string` act the same way. Even C's dynamic arrays (`int x[]`) can be thought of the same way (if one avoids thinking of them as pointers). So why not consider `str` and `[T]` conglomerates of a fixed size containing the pointers (start, length and capacity or whatever) needed? Semantically it's the same while syntactically it's simpler. Slices will need new names of course, but I think the resulting decrease in confusion will be worth it. (D's developers tried to go the other way, with all arrays and slices being effectively copy-on-write slices, before realising that discrete array/slices types _were_ needed.) DH ___ 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
Re: [rust-dev] About owned pointer
C++'s `string` and `vectorT` are objects containing two or three pointers.
For that one pays performance penalty in C++ as string and vector
instances are passed by references resulting in double indirection
when accessing the elements. I suppose it could help to think about
strings in Rust similar to variable-sized structs in C like:
struct MyString {
unsigned int bytelength;
unsigned int data[];
};
As in Rust such struct cannot be instantiated and one typically uses
malloc/alloca to allocate instances and then just pass around the
resulting pointers.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On 11/08/2013 05:47 PM, Igor Bukanov wrote:
C++'s `string` and `vectorT` are objects containing two or three pointers.
For that one pays performance penalty in C++ as string and vector
instances are passed by references resulting in double indirection
when accessing the elements. I suppose it could help to think about
strings in Rust similar to variable-sized structs in C like:
struct MyString {
unsigned int bytelength;
unsigned int data[];
};
As in Rust such struct cannot be instantiated and one typically uses
malloc/alloca to allocate instances and then just pass around the
resulting pointers.
I like this version precisely for the reason it avoids double indirection. I use
it whenever I need weighted strings in C (strings that know their weight,
Pascal strings in fact) [1]. It works fine, is easy on the implementation side,
just terribly annoying w/o syntactic support. Same for arrays, both fixed (but
variable, in the sense of not predefined) and dynamic size.
It's all fine in my view for a language like Rust, provided it remains an
implementation choice. Meaning, whether the representation of say a static array
is a {p, n} struct or such a variable-sized structs is transparent on the
language side.
What are the present implementations of strings and arrays in Rust? And what
about fixed size (esp for strings)?
Denis
[1] Actually, I rather just use a pointer, with the size written before the
first string byte or array item, like true Pascal strings, but the result is the
same.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On 11/8/13 9:38 AM, Benjamin Striegel wrote: I would like to take steps to move to that world post Rust 1.0. I'd be interested to read more about this, and the reasons why it must be deferred until after 1.0. Is it just too much work to do right now, or does it require some broader ambitious feature (HKT, etc)? IIRC Niko mentioned that it requires higher kinded types. I hadn't thought too much about the precise definition of the smart pointer trait. But it's also too much work to do right now, and doesn't seem like it's going to get us into much trouble regarding backwards compatibility. Having one ultra-common smart pointer type built into the language seems rather harmless. After all, in C++ there is a default `operator new`, and having to say `new(Unique)` would be pretty annoying for the commonest type of pointer. Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer -- explicit specification
On 11/08/2013 09:43 AM, Gaetan wrote:
I agree, I don't understand the syntax here.
Look at the Url class:
pub struct Url {
scheme: ~str,
user: OptionUserInfo,
host: ~str,
port: Option~str,
path: ~str,
query: Query,
fragment: Option~str
}
pub type Query = ~[(~str, ~str)];
fn split_char_first(s: str, c: char) - (~str, ~str) {
...
if index+mat == len {
return (s.slice(0, index).to_owned(), ~);
}
}
Isn't simpler, and easier to read, if we write it
pub struct Url {
scheme: str,
user: OptionUserInfo,
host: str,
port: Optionstr,
path: str,
query: Query,
fragment: Optionstr
}
pub type Query = [(str, str)];
fn split_char_first(s: str, c: char) - (str, str) {
...
if index+mat == len {
return (s.slice(0, index).to_owned(), );
}
}
KISS !
-
Gaetan
Sure! I'd strongly support that (exactly the changes you propose).
But I thought the obligation to explicitely specify the pointer type was a
side-effect of the variety of pointer kinds in Rust: If in Rust one is to able
to choose which kind of pointer is used, then, well, we must write it down
somewhere somehow, no?
Some of the strings or arrays above (or more generally structured data), may be
shared, referenced from other structured thingies, in which case we'd need a
non-owned pointer (probably @). Or do I misunderstand?
Somewhat related but distinct, I thought we could get rid of specifying the
pointer type for function input: seems to be always , no? Or mut when changed
inside the func, but the compiler can probably tell that; also, if the param is
not changed, having mut does not affect the semantics anyway... Or, if pointed
function input is not always / mut, systematically, in current Rust code,
could it be anyway, without exaggerated semantic constraint or efficiency loss?
Still related but distinct, what other uses for (and mut) than function
input?
Denis
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On 11/08/2013 09:53 AM, Daniel Micay wrote: It couldn't be called `str`, because `str` is a slice. Why couldn't str be slices? (eg somewhat like arrays are slices in D) Also, i don't understand literals in Rust currently. Same for static arrays. Denis ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
Because then `str` would not be a dynamically sized type. Please read the blog posts on dynamically sized types. spir denis.s...@gmail.com wrote: On 11/08/2013 09:53 AM, Daniel Micay wrote: It couldn't be called `str`, because `str` is a slice. Why couldn't str be slices? (eg somewhat like arrays are slices in D) Also, i don't understand literals in Rust currently. Same for static arrays. Denis ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On 11/08/2013 07:20 PM, Patrick Walton wrote: Because then `str` would not be a dynamically sized type. (I'm not convinced --yet-- strings *must* have dynamic size at all, as I never need this feature even if I do quite a lot of text processing. When generating runtime produced strings, I'd rather concat all bits at once at the very end, thus knowing the final size. No support for this is needed: one never writes into a growable string buffer, instead always concat all at once. But this may be another, distinct story. And there may be use cases I'm unaware of, even common ones.) Please read the blog posts on dynamically sized types. All right, I'll do. PS: Except I cannot find them. Don't seem listed in the list of blog post at https://github.com/mozilla/rust/wiki/Docs Also not in the archives of your own blog at: http://pcwalton.github.io/blog/archives/ Denis spir denis.s...@gmail.com wrote: On 11/08/2013 09:53 AM, Daniel Micay wrote: It couldn't be called `str`, because `str` is a slice. Why couldn't str be slices? (eg somewhat like arrays are slices in D) Also, i don't understand literals in Rust currently. Same for static arrays. Denis ___ 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
Re: [rust-dev] About owned pointer
On 8 November 2013 18:35, Patrick Walton pcwal...@mozilla.com wrote:
But Daniel did some performance measurements and found that this had
suboptimal performance characteristics when compared to:
struct ~str {
char *ptr;
int size;
int cap;
}
So we're changing to the latter.
Does this mean that when ~str is passed as a parameter the compiler
copies 3 words and that makes things faster?
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
Now I'm confused; doesn't this mean str is fixed size, so the proposal to
just use str for the 3-word struct and have ~str and str just be the
normal thing makes sense after all?
On Fri, Nov 8, 2013 at 8:56 PM, Marvin Löbel loebel.mar...@gmail.comwrote:
On 11/08/2013 07:50 PM, Igor Bukanov wrote:
On 8 November 2013 18:35, Patrick Walton pcwal...@mozilla.com wrote:
But Daniel did some performance measurements and found that this had
suboptimal performance characteristics when compared to:
struct ~str {
char *ptr;
int size;
int cap;
}
So we're changing to the latter.
Does this mean that when ~str is passed as a parameter the compiler
copies 3 words and that makes things faster?
According to https://github.com/mozilla/rust/issues/8981, yes and yes
apparently. :)
You rarely pass around a ~[T] directly anyway, usually you work with
slices to them, which right now consist of exactly two words. (Though that
might change to three words too for unrelated consistency reasons)
Other speed improvements come from the fact that empty vectors no longer
allocate, and that you no longer need to dereference a pointer into heap
memory to get the size of an vector.
___
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
Re: [rust-dev] About owned pointer
Except I cannot find them. The dynamically-sized type posts are sort of scattered all over Niko's blog. You can start here: http://smallcultfollowing.com/babysteps/blog/2013/04/30/dynamically-sized-types/ for a general overview. On Fri, Nov 8, 2013 at 1:38 PM, spir denis.s...@gmail.com wrote: On 11/08/2013 07:20 PM, Patrick Walton wrote: Because then `str` would not be a dynamically sized type. (I'm not convinced --yet-- strings *must* have dynamic size at all, as I never need this feature even if I do quite a lot of text processing. When generating runtime produced strings, I'd rather concat all bits at once at the very end, thus knowing the final size. No support for this is needed: one never writes into a growable string buffer, instead always concat all at once. But this may be another, distinct story. And there may be use cases I'm unaware of, even common ones.) Please read the blog posts on dynamically sized types. All right, I'll do. PS: Except I cannot find them. Don't seem listed in the list of blog post at https://github.com/mozilla/ rust/wiki/Docs Also not in the archives of your own blog at: http://pcwalton.github.io/ blog/archives/ Denis spir denis.s...@gmail.com wrote: On 11/08/2013 09:53 AM, Daniel Micay wrote: It couldn't be called `str`, because `str` is a slice. Why couldn't str be slices? (eg somewhat like arrays are slices in D) Also, i don't understand literals in Rust currently. Same for static arrays. Denis ___ 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 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
So, the core question is whether we think of str as an object or as a pointer. Either we see it as an object (with fixed size, 3 words), which internally holds a nested pointer to a dynamically-sized region of characters; or we see it as a direct smart pointer to this array. The physics of str seem to be the former, but the abstraction presented to the programmer is the latter. Of course, there's also value in providing clean abstractions, but this is a leaky one. For example, it isn't very clean to have a concrete type T which allows ~T, T, @T, *T but forbids having a simple T (unless one is talking about a trait, which str isn't). It is weird and causes all sort of edge cases when trying to write generic code. Also, str != ~[u8] (for good reason). The internal array is hidden anyway, so pretending to be a smart pointer to it doesn't make a lot of sense to me. Of course there's a very related issue of whether we see a vector as a smart pointer or as an object, so even if str was == ~[u8] it would probably still make sense to view it as an object :-) In general, in a system language, one wants the low-level abstractions (such as str) to be close to the physics, so people would be able to easily reason about the code behavior. This would also lend support to the proposal of seeing str as a struct and not as a pointer. On Fri, Nov 8, 2013 at 11:22 PM, Patrick Walton pcwal...@mozilla.comwrote: On 11/8/13 11:33 AM, Oren Ben-Kiki wrote: Now I'm confused; doesn't this mean str is fixed size, so the proposal to just use str for the 3-word struct and have ~str and str just be the normal thing makes sense after all? No, `str` is not fixed-size. An *owned pointer* to a string is fixed-size (as all pointers are), but the string *itself* is dynamically sized. The size of pointers changes based on the kind of thing they point to. Patrick ___ 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
Re: [rust-dev] About owned pointer
On 11/8/13 2:00 PM, Oren Ben-Kiki wrote: Also, str != ~[u8] (for good reason). The internal array is hidden anyway, so pretending to be a smart pointer to it doesn't make a lot of sense to me. Of course there's a very related issue of whether we see a vector as a smart pointer or as an object, so even if str was == ~[u8] it would probably still make sense to view it as an object :-) No! Read the thread! You need `str and `'static str` for performance as well as `~str`. Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On 11/8/13 2:08 PM, Oren Ben-Kiki wrote: I don't follow. ~Trait is a pointer, and therefore its size is fixed. There are checks in place to prevent using a trait as a type (there's a nice error message from the compiler saying using trait as a type :-)... So the Trait in ~Trait isn't a _type_, right? :-) No, the `Trait` in `~Trait` is a type under the dynamically sized types proposal. It is a type, just a dynamically sized one. Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
Yes, the down side is another level of indirection. This could be optimized away for 'static str, but not for str. Good point. On Sat, Nov 9, 2013 at 12:06 AM, Patrick Walton pcwal...@mozilla.comwrote: On 11/8/13 2:00 PM, Oren Ben-Kiki wrote: Also, str != ~[u8] (for good reason). The internal array is hidden anyway, so pretending to be a smart pointer to it doesn't make a lot of sense to me. Of course there's a very related issue of whether we see a vector as a smart pointer or as an object, so even if str was == ~[u8] it would probably still make sense to view it as an object :-) No! Read the thread! You need `str and `'static str` for performance as well as `~str`. Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
Is there a place where one can see new proposals (is it all in the issues list in github and/or here, or is there a 3rd place?) E.g. there's the whole lets-get-rid-of-@, and now is the 1st time I heard there's a dynamically sized types proposal... well, other than in passing in this thread, that is. On Sat, Nov 9, 2013 at 12:09 AM, Patrick Walton pcwal...@mozilla.comwrote: On 11/8/13 2:08 PM, Oren Ben-Kiki wrote: I don't follow. ~Trait is a pointer, and therefore its size is fixed. There are checks in place to prevent using a trait as a type (there's a nice error message from the compiler saying using trait as a type :-)... So the Trait in ~Trait isn't a _type_, right? :-) No, the `Trait` in `~Trait` is a type under the dynamically sized types proposal. It is a type, just a dynamically sized one. Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On 11/08/2013 02:06 PM, Patrick Walton wrote: On 11/8/13 2:00 PM, Oren Ben-Kiki wrote: Also, str != ~[u8] (for good reason). The internal array is hidden anyway, so pretending to be a smart pointer to it doesn't make a lot of sense to me. Of course there's a very related issue of whether we see a vector as a smart pointer or as an object, so even if str was == ~[u8] it would probably still make sense to view it as an object :-) No! Read the thread! You need `str and `'static str` for performance as well as `~str`. This thread is has been running off the rails a bit. Let's all please take a step back. This subject is one of the most subtle areas of Rust's type system, is in flux, and a lot of our plans about it are scattered across various places and passed around through informal conversation. It's understandable that there's confusion and debate here. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On 11/8/13 2:10 PM, Oren Ben-Kiki wrote: Yes, the down side is another level of indirection. This could be optimized away for 'static str, but not for str. Good point. I apologize for snapping at you. This thread has become not particularly productive. I'm welcome to alternative suggestions, but I'd like to suggest that any proposal needs to accommodate: 1. A coherent story for smart pointers to existential types in which the size is not known (e.g. `~Trait`). 2. Accommodation for extending the language for custom smart pointers. 3. A story for vectors, including custom ones. 4. Garbage-collected vectors and strings. 5. Lifetime-bounded pointers to array slices. Array slices must not allow access outside the bounds of the slice, even if those elements are within the original array. 6. C-like levels of efficiency for vectors and arrays, without extra levels of indirection. 7. The ability to push onto a unique array if capacity is available without copying all the elements. 8. Constant strings stored in static memory, without life-before-main. 9. Memory safety. 10. Unicode safety for strings: ensuring that all strings have valid UTF-8 in them at all times. There are probably more, but that's my initial list. I know that many people don't like the fact that, syntactically, vectors and strings have a sigil in front of them, but please consider that there are many design constraints here. What works for another language may not work for Rust, because of these constraints. Note that I *am* open to other possibilities :) I don't mean to shut people down! But the design space here is very limited. Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On 11/8/13 2:12 PM, Oren Ben-Kiki wrote: Is there a place where one can see new proposals (is it all in the issues list in github and/or here, or is there a 3rd place?) E.g. there's the whole lets-get-rid-of-@, and now is the 1st time I heard there's a dynamically sized types proposal... well, other than in passing in this thread, that is. Here's the stuff we have on dynamically sized types (DSTs): https://github.com/mozilla/rust/issues/6308 http://smallcultfollowing.com/babysteps/blog/2013/04/30/dynamically-sized-types/ http://smallcultfollowing.com/babysteps/blog/2013/05/13/recurring-closures-and-dynamically-sized-types/ Notice that the representation changes discussed in Niko's initial blog post are out of date. We aren't planning to do them, since there doesn't seem to be a soundness problem with having smart pointers like like `~` having different representations depending on what they point to. Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
No need to apologize. You are quite right, this is tricky and there's a good reason for the current design choices (perhaps there are better, but they are far from obvious). I wish I could put more time into deep thinking about this... which, of course, you can :-) On Sat, Nov 9, 2013 at 12:32 AM, Patrick Walton pcwal...@mozilla.comwrote: On 11/8/13 2:19 PM, Brian Anderson wrote: This thread is has been running off the rails a bit. Let's all please take a step back. This subject is one of the most subtle areas of Rust's type system, is in flux, and a lot of our plans about it are scattered across various places and passed around through informal conversation. It's understandable that there's confusion and debate here. Agreed, and again, my apologies. Patrick ___ 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
Re: [rust-dev] About owned pointer
On 09/11/13 09:27, Patrick Walton wrote: On 11/8/13 2:12 PM, Oren Ben-Kiki wrote: Is there a place where one can see new proposals (is it all in the issues list in github and/or here, or is there a 3rd place?) E.g. there's the whole lets-get-rid-of-@, and now is the 1st time I heard there's a dynamically sized types proposal... well, other than in passing in this thread, that is. Here's the stuff we have on dynamically sized types (DSTs): https://github.com/mozilla/rust/issues/6308 http://smallcultfollowing.com/babysteps/blog/2013/04/30/dynamically-sized-types/ http://smallcultfollowing.com/babysteps/blog/2013/05/13/recurring-closures-and-dynamically-sized-types/ Notice that the representation changes discussed in Niko's initial blog post are out of date. We aren't planning to do them, since there doesn't seem to be a soundness problem with having smart pointers like like `~` having different representations depending on what they point to. This will make transmuting ~ to get a * (e.g., to allocate memory for storage in an Rc, with automatic clean-up by transmuting back to ~ on destruction) harder to get right, won't it? Patrick ___ 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
Re: [rust-dev] About owned pointer
On 09/11/13 09:44, Patrick Walton wrote: On 11/8/13 2:43 PM, Huon Wilson wrote: This will make transmuting ~ to get a * (e.g., to allocate memory for storage in an Rc, with automatic clean-up by transmuting back to ~ on destruction) harder to get right, won't it? You'll want a `Sized` bound, I think. Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev Ah, of course. Presumably this means that `RcTrait` or `Rcstr` would require a separate code-path? Huon ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On 8 November 2013 23:10, Oren Ben-Kiki o...@ben-kiki.org wrote: Yes, the down side is another level of indirection. This could be optimized away for 'static str, but not for str. Good point. The level of indirection comes from passing strings as str, not just as a plain str. But this raises the question. For immutable values implementing T parameter as T should not be observable from the safe code, right? If so why not to declare that T as a parameter is not a pointer but rather a hint to use the fastest way to pass an instance of T to the function. Then one can use str as a parameter without any performance impact due to indirection even if str itself is fixed-sized 3-word block pointing to the heap allocated data. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On 09/11/13 10:06, Igor Bukanov wrote: On 8 November 2013 23:10, Oren Ben-Kiki o...@ben-kiki.org wrote: Yes, the down side is another level of indirection. This could be optimized away for 'static str, but not for str. Good point. The level of indirection comes from passing strings as str, not just as a plain str. But this raises the question. For immutable values implementing T parameter as T should not be observable from the safe code, right? If so why not to declare that T as a parameter is not a pointer but rather a hint to use the fastest way to pass an instance of T to the function. Then one can use str as a parameter without any performance impact due to indirection even if str itself is fixed-sized 3-word block pointing to the heap allocated data. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev `T` is pointer-sized but `T` isn't always. (I believe that LLVM will optimise references to pass-by-value in certain circumstances; presumably when functions are internal to a compilation unit.) Huon ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On 11/8/13 3:06 PM, Igor Bukanov wrote: On 8 November 2013 23:10, Oren Ben-Kiki o...@ben-kiki.org wrote: Yes, the down side is another level of indirection. This could be optimized away for 'static str, but not for str. Good point. The level of indirection comes from passing strings as str, not just as a plain str. But this raises the question. For immutable values implementing T parameter as T should not be observable from the safe code, right? If so why not to declare that T as a parameter is not a pointer but rather a hint to use the fastest way to pass an instance of T to the function. Then one can use str as a parameter without any performance impact due to indirection even if str itself is fixed-sized 3-word block pointing to the heap allocated data. For one, you can pass substrings as `str`. Those can't be optimized away so easily. Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On Fri, Nov 8, 2013 at 6:06 PM, Igor Bukanov i...@mir2.org wrote: On 8 November 2013 23:10, Oren Ben-Kiki o...@ben-kiki.org wrote: Yes, the down side is another level of indirection. This could be optimized away for 'static str, but not for str. Good point. The level of indirection comes from passing strings as str, not just as a plain str. But this raises the question. For immutable values implementing T parameter as T should not be observable from the safe code, right? If so why not to declare that T as a parameter is not a pointer but rather a hint to use the fastest way to pass an instance of T to the function. Then one can use str as a parameter without any performance impact due to indirection even if str itself is fixed-sized 3-word block pointing to the heap allocated data. The only way you could avoid pointer indirection is by making the element length part of the type, like fixed-size vectors. For strings, there's not really a clearly meaningful element length (bytes? code points? graphemes?). An alternate vector/string doing small string optimization makes more sense to me. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On 9 November 2013 00:08, Huon Wilson dbau...@gmail.com wrote: `T` is pointer-sized but `T` isn't always. If the size of T is not known, then obviously such optimization is not applicable, The point is about T where T is fixed-sized 1-4 word thing. (I believe that LLVM will optimise references to pass-by-value in certain circumstances; presumably when functions are internal to a compilation unit.) But what about declaring that such optimization is always valid and even require it on the level of ABI? ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On 11/8/13 3:13 PM, Igor Bukanov wrote:
On 9 November 2013 00:08, Huon Wilson dbau...@gmail.com wrote:
`T` is pointer-sized but `T` isn't always.
If the size of T is not known, then obviously such optimization is
not applicable, The point is about T where T is fixed-sized 1-4 word
thing.
(I believe that LLVM will optimise references to pass-by-value in certain
circumstances; presumably when functions are internal to a compilation
unit.)
But what about declaring that such optimization is always valid and
even require it on the level of ABI?
I don't see how you can without defeating separate compilation. If I am
a function:
fn f(s: ~str) {}
It is `f`'s responsibility to free `s` at the end. That can't be done if
this optimization has been performed.
Patrick
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On Fri, Nov 8, 2013 at 6:13 PM, Igor Bukanov i...@mir2.org wrote: On 9 November 2013 00:08, Huon Wilson dbau...@gmail.com wrote: `T` is pointer-sized but `T` isn't always. If the size of T is not known, then obviously such optimization is not applicable, The point is about T where T is fixed-sized 1-4 word thing. (I believe that LLVM will optimise references to pass-by-value in certain circumstances; presumably when functions are internal to a compilation unit.) But what about declaring that such optimization is always valid and even require it on the level of ABI? If you're using dynamic linking, the call overhead makes the cost of having an extra pointer in the CPU cache irrelevant. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On 9 November 2013 00:15, Patrick Walton pcwal...@mozilla.com wrote:
I don't see how you can without defeating separate compilation. If I am a
function:
fn f(s: ~str) {}
It is `f`'s responsibility to free `s` at the end. That can't be done if
this optimization has been performed.
This is about only optimizing fn f(t: T) cases. Suppose one has a
custom 3-word struct with a destructor. Then with the current setup
one cannot hope that T as a parameter would be just as efficient as
3-word ~str as the compiler uses an extra indirection. So the idea is
to say to the programmer: do not worry about this and always use T as
a parameter type - the compiler will optimize it using the best mode
using internally pass-by-value if necessary.
With such optimization in place there would be no difference between
~str and struct MyStruct {s: ~str} as both ~str and MyStruct as a
parameter generates exactly the same code.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On Nov 8, 2013, at 2:21 PM, Patrick Walton pcwal...@mozilla.com wrote: I know that many people don't like the fact that, syntactically, vectors and strings have a sigil in front of them, but please consider that there are many design constraints here. What works for another language may not work for Rust, because of these constraints. Personally, I find it great that they have a sigil in front of them. It reminds me that they're stored in the heap. -Kevin ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On Sat, Nov 9, 2013 at 12:36 AM, Kevin Ballard ke...@sb.org wrote: On Nov 8, 2013, at 2:21 PM, Patrick Walton pcwal...@mozilla.com wrote: I know that many people don't like the fact that, syntactically, vectors and strings have a sigil in front of them, but please consider that there are many design constraints here. What works for another language may not work for Rust, because of these constraints. Personally, I find it great that they have a sigil in front of them. It reminds me that they're stored in the heap. -Kevin Since library containers, smart pointers and other types don't have them, I don't think it's helpful in that regard. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On Nov 8, 2013, at 9:38 PM, Daniel Micay danielmi...@gmail.com wrote: On Sat, Nov 9, 2013 at 12:36 AM, Kevin Ballard ke...@sb.org wrote: On Nov 8, 2013, at 2:21 PM, Patrick Walton pcwal...@mozilla.com wrote: I know that many people don't like the fact that, syntactically, vectors and strings have a sigil in front of them, but please consider that there are many design constraints here. What works for another language may not work for Rust, because of these constraints. Personally, I find it great that they have a sigil in front of them. It reminds me that they're stored in the heap. -Kevin Since library containers, smart pointers and other types don't have them, I don't think it's helpful in that regard. Well no, you can't assume that the absence of a sigil means the absence of heap storage. But for types that are possibly not stored on the heap, such as str (which can be 'static str) and [T] (which can be a fixed-size stack-allocated vector), the ~ is a useful distinction. -Kevin___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On 11/8/13 3:11 PM, Daniel Micay wrote: The only way you could avoid pointer indirection is by making the element length part of the type, like fixed-size vectors. For strings, there's not really a clearly meaningful element length (bytes? code points? graphemes?). An alternate vector/string doing small string optimization makes more sense to me. I think it's worth thinking about how to allow for custom vector/string implementations in this scenario. There are a couple of directions I can see us going: 1. Keep `~[T]` as today and implement overloadable literal syntax for `SmallString`/`SmallVector`. Or: 2. Implement things like `SmallString`/`SmallVector` as custom smart pointers that know how to store elements of a vector inline. These kind of custom smart pointers would be hard-wired to particular kinds of DSTs. So, for example, we could imagine: let x: SmallVector[int] = new(SmallVector) [ 1, 2, 3, 4 ]; Option (2) is intriguing to me, because it allows us to possibly get away with not having literal syntax and taking advantage of DSTs to get us the benefits of custom vector/string representations. But it seems too good to be true :) There may be something I'm missing... Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On Sat, Nov 9, 2013 at 12:43 AM, Kevin Ballard ke...@sb.org wrote: Well no, you can't assume that the absence of a sigil means the absence of heap storage. But for types that are possibly *not* stored on the heap, such as str (which can be 'static str) and [T] (which can be a fixed-size stack-allocated vector), the ~ is a useful distinction. -Kevin Slices are just a view into some block of memory and are truly a low-level building block without any incentive for reimplementation. Rust's built-in vector/string types lack allocator support, so alternate implementations will end up being created. There's also a need for small vectors/strings, and perhaps reference-counted slices. LLVM is a good example of a modern, performance-concious C++ project. Here are the approximate counts for the various vector types: ArrayRef: 1276 (fixed-size vectors aren't used through a C++11-style template, the number is probably 10k or 20k) std::vector: 3078 SmallVector: 5076 std::string: 3648 StringRef: 4596 SmallString: 493 C++11 also supports reference counted slices of memory via `std::shared_ptr`, but I'm unsure if LLVM uses a similar type. This would be the following set of types: * [T] * [T, ..N] * VecT * SmallVecT, N * str * Str * SmallStrT, N * RcSliceT * RcMutSliceT With support for allocators like the C++ standard library, it's messier since Rust lacks default type parameters: * [T] * [T, ..N] * VecT, A * SmallVecT, N, A * str * StrA * SmallStrT, N, A * RcSliceT, A * RcMutSliceT, A This is what I plan on implementing for rust-core, regardless of whether I convince anyone it's a good idea for the standard library. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On 11/8/13 10:49 PM, Daniel Micay wrote: This is what I plan on implementing for rust-core, regardless of whether I convince anyone it's a good idea for the standard library. I do think the Rust standard library should support allocators and small vector optimization, for what it's worth. Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On Sat, Nov 9, 2013 at 1:52 AM, Patrick Walton pcwal...@mozilla.com wrote: On 11/8/13 10:49 PM, Daniel Micay wrote: This is what I plan on implementing for rust-core, regardless of whether I convince anyone it's a good idea for the standard library. I do think the Rust standard library should support allocators and small vector optimization, for what it's worth. Would you add default type parameters to the language or just use a separate type for allocator-aware containers? (The third option, have them *all* be allocator aware, makes for horrendous UI) ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On 11/8/13 10:55 PM, Corey Richardson wrote: Would you add default type parameters to the language or just use a separate type for allocator-aware containers? (The third option, have them *all* be allocator aware, makes for horrendous UI) Probably using a separate type, but I wouldn't rule out the first option. Mostly I just wanted to make it clear that allocators and small vector optimization *are* on the table for the Rust standard library. For one thing, these are important optimizations for Web browser engines, and I don't want to leave that performance on the table when we've come so far with the lifetime/borrowing system. Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] About owned pointer
Hello I really the concept of owned pointers, and I'm wondering if it could be the default. I mean, the more I use it, the more I tend to use it everywhere, and it seem any average user-code (ie, not the rust compiler itself) will have a lot of ~var anywhere, let i=~5, ..., more than the other variable initialization. Look at the unit tests for libstd or libextra. Why not having the default syntax be owned pointers, and the ~ syntax (or another one) be the syntax for creating variable on the heap? let i=5; // owned pointer let j=~5; // heap value Regards, - Gaetan ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
Why not having the default syntax be owned pointers, and the ~ syntax (or another one) be the syntax for creating variable on the heap? ~ does allocate on the heap. Without ~ you allocate on the stack. Regards, Rob. On 7 November 2013 10:03, Gaetan gae...@xeberon.net wrote: Hello I really the concept of owned pointers, and I'm wondering if it could be the default. I mean, the more I use it, the more I tend to use it everywhere, and it seem any average user-code (ie, not the rust compiler itself) will have a lot of ~var anywhere, let i=~5, ..., more than the other variable initialization. Look at the unit tests for libstd or libextra. Why not having the default syntax be owned pointers, and the ~ syntax (or another one) be the syntax for creating variable on the heap? let i=5; // owned pointer let j=~5; // heap value Regards, - Gaetan ___ 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
Re: [rust-dev] About owned pointer
sorry for the confusion - Gaetan 2013/11/7 Robert Knight robertkni...@gmail.com Why not having the default syntax be owned pointers, and the ~ syntax (or another one) be the syntax for creating variable on the heap? ~ does allocate on the heap. Without ~ you allocate on the stack. Regards, Rob. On 7 November 2013 10:03, Gaetan gae...@xeberon.net wrote: Hello I really the concept of owned pointers, and I'm wondering if it could be the default. I mean, the more I use it, the more I tend to use it everywhere, and it seem any average user-code (ie, not the rust compiler itself) will have a lot of ~var anywhere, let i=~5, ..., more than the other variable initialization. Look at the unit tests for libstd or libextra. Why not having the default syntax be owned pointers, and the ~ syntax (or another one) be the syntax for creating variable on the heap? let i=5; // owned pointer let j=~5; // heap value Regards, - Gaetan ___ 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
Re: [rust-dev] About owned pointer
On 11/07/2013 11:03 AM, Gaetan wrote: I mean, the more I use it, the more I tend to use it everywhere, and it seem any average user-code (ie, not the rust compiler itself) will have a lot of ~var anywhere, let i=~5, ..., more than the other variable initialization. Look at the unit tests for libstd or libextra. The unit tests are not necessary good code examples. In actual good rust code, you'd almost never need to use a heap allocated ~T if you can use a T on the stack. There is also no problem with that: A ~T behaves almost exactly like a T, the only exceptions being that ~T is always pointer sized, and that ~T always has a destructor, which means it always gets moved around instead of possibly being implicitly copied. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
Don't worry, our pointers _are_ more confusing compared to many other languages after all. :) Am 07.11.2013 11:25 schrieb Marvin Löbel loebel.mar...@gmail.com: On 11/07/2013 11:03 AM, Gaetan wrote: I mean, the more I use it, the more I tend to use it everywhere, and it seem any average user-code (ie, not the rust compiler itself) will have a lot of ~var anywhere, let i=~5, ..., more than the other variable initialization. Look at the unit tests for libstd or libextra. The unit tests are not necessary good code examples. In actual good rust code, you'd almost never need to use a heap allocated ~T if you can use a T on the stack. There is also no problem with that: A ~T behaves almost exactly like a T, the only exceptions being that ~T is always pointer sized, and that ~T always has a destructor, which means it always gets moved around instead of possibly being implicitly copied. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On Thu, Nov 7, 2013 at 5:03 AM, Gaetan gae...@xeberon.net wrote: Hello I really the concept of owned pointers, and I'm wondering if it could be the default. I mean, the more I use it, the more I tend to use it everywhere, and it seem any average user-code (ie, not the rust compiler itself) will have a lot of ~var anywhere, let i=~5, ..., more than the other variable initialization. Look at the unit tests for libstd or libextra. Why not having the default syntax be owned pointers, and the ~ syntax (or another one) be the syntax for creating variable on the heap? let i=5; // owned pointer let j=~5; // heap value Regards, - Gaetan Owned boxes shouldn't be commonly used. There's close to no reason to use one for anything but a recursive data structure or in rare cases for an owned trait object. http://static.rust-lang.org/doc/master/tutorial.html#boxes It's important to note that ~[T] and ~str are not owned boxes. They're just sugar for dynamic arrays, and are common containers. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On Thu, Nov 7, 2013 at 7:49 PM, Jason Fager jfa...@gmail.com wrote: Can you speak a little to the practical differences between owned boxes and ~[T]/~str? How does the difference affect how I should use each? I wrote the section on owned boxes in the tutorial currently in master, so I would suggest reading that. It's very rare for there to be a use case for an owned box outside of a recursive data structure or plugin system (traits as objects). The coverage in the tutorial of vectors/strings is not only lacking in depth but is also *incorrect*, so I understand why there's a lot of confusion about them. Vectors/strings are containers, and aren't connected to owned boxes any more than HashMap/TreeMap/TrieMap. I would prefer it if the syntactic sugar didn't exist and we just had generic container literals, because it seems to end up causing a lot of confusion. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] About owned pointer
Let me ask another way: what's wrong with thinking of ~ just as meaning allocate to the heap and subject to move semantics? When would that simplification bite me in the ass regarding owned boxes vs strs/vecs? I get that I should very rarely want that for things that aren't dynamic containers or recursive data structures. But beyond that, am I ever going to get myself in trouble not remembering the details of the difference between how ~T works vs ~[T]? On Thursday, November 7, 2013, Daniel Micay wrote: On Thu, Nov 7, 2013 at 7:49 PM, Jason Fager jfa...@gmail.com wrote: Can you speak a little to the practical differences between owned boxes and ~[T]/~str? How does the difference affect how I should use each? I wrote the section on owned boxes in the tutorial currently in master, so I would suggest reading that. It's very rare for there to be a use case for an owned box outside of a recursive data structure or plugin system (traits as objects). The coverage in the tutorial of vectors/strings is not only lacking in depth but is also *incorrect*, so I understand why there's a lot of confusion about them. Vectors/strings are containers, and aren't connected to owned boxes any more than HashMap/TreeMap/TrieMap. I would prefer it if the syntactic sugar didn't exist and we just had generic container literals, because it seems to end up causing a lot of confusion. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On Thu, Nov 7, 2013 at 8:40 PM, Jason Fager jfa...@gmail.com wrote: Let me ask another way: what's wrong with thinking of ~ just as meaning allocate to the heap and subject to move semantics? When would that simplification bite me in the ass regarding owned boxes vs strs/vecs? I get that I should very rarely want that for things that aren't dynamic containers or recursive data structures. But beyond that, am I ever going to get myself in trouble not remembering the details of the difference between how ~T works vs ~[T]? The heap allocation is a means to an end rather than a useful property. There are lots of types in the standard library with destructors, including most of the containers. There's a deeper connection between TreeMap and an owned box than between owned vectors and owned boxes. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
