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`
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
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
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
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
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
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
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
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
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:
// 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
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:
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
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:
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
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
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
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
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
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
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) { }`.
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
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
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
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
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
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 =
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
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
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
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
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
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
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
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,
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_,
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
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
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
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,
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,
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
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
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,
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
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
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,
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
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
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.
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
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
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
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
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
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
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
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.
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
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
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
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
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.
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
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
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)
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
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
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
69 matches
Mail list logo
