On Mon, Apr 14, 2014 at 10:32 PM, Daniel Micay danielmi...@gmail.comwrote:
On 14/04/14 12:41 PM, Matthieu Monrocq wrote:
Memory fragmentation is a potential issue in all languages that not use
a Compacting GC, so yes.
It's much less of an issue than people make it out to be on 32-bit, and
Hi everyone,
I'd like to remove the `~foo` literal syntax for owned strings in both
expressions and patterns. After dynamically sized types, this syntax is
the last remnant of the strange parser behavior by which the parser does
something different for `~foo` and `~(foo)` (i.e. by which it
I can finally retire that bookmark to
https://mail.mozilla.org/pipermail/rust-dev/2013-April/003867.html !
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
On Tue, Apr 15, 2014 at 10:20 AM, Steve Klabnik st...@steveklabnik.comwrote:
I can finally retire that bookmark to
https://mail.mozilla.org/pipermail/rust-dev/2013-April/003867.html !
How will that change though? Won't we still have to call `.equiv()`?
Furthermore, wasn't the plan to use
On 04/15/2014 01:12 PM, Patrick Walton wrote:
The new replacement for `~foo` will be `foo.to_owned()`. You can
also use the `fmt!()` macro or the `.to_str()` function. Post-DST, you
will likely also be able to write `Heap::from(foo)`.
Why not `box foo`? Is that scheduled to break?
-SL
`box foo` would create a SomeBox'static str, as outlined in the
meeting notes:
box foo - Heap'static Str
foo.to_owned() - HeapStr (or ~Str)
Heap::from(foo) - HeapStr (or ~Str)
Rc::from(foo) - RcStr
On Tue, Apr 15, 2014 at 2:06 PM, SiegeLord slab...@aim.com wrote:
On 04/15/2014 01:12 PM, Patrick
So the new Vec and Str/StrBuf types are all reference types, correct?
What happens if we pass around a borrowed or owned pointer to one of these
types? Won't there be an extra level of indirection to get to the
underlying data pointer?
--
Ziad
On Tue, Apr 15, 2014 at 11:10 AM, Corey Richardson
On 15/04/14 12:46 PM, Matthieu Monrocq wrote:
By the way, do you have any idea how this is going to pan out on
processors like the Mill CPU where the address space is shared among
processes ?
x86_64 and ARM64 really have a 48-bit address space (cut down to 47-bit
by Linux to separate the
On 15/04/14 02:25 PM, Ziad Hatahet wrote:
So the new Vec and Str/StrBuf types are all reference types, correct?
What happens if we pass around a borrowed or owned pointer to one of
these types? Won't there be an extra level of indirection to get to the
underlying data pointer?
There's close
Hi, I made an issue at https://github.com/mozilla/rust/issues/13492
Thanks
On Sat, Apr 12, 2014 at 7:20 PM, Michael Woerister
michaelwoeris...@posteo.de wrote:
If the extern crate is compiled with debug symbols, this should just
work. Unfortunately, I don't think there is a 'configure'
Currently if I try to specify lifetimes in the return types of overloaded
operators like Index ([]), I get an error message :
method `index` has an incompatible type for trait: expected concrete
lifetime, but found bound lifetime parameter
Why has this restriction been placed, given that I can
On 04/15/2014 10:12 AM, Patrick Walton wrote:
Hi everyone,
I'd like to remove the `~foo` literal syntax for owned strings in both
expressions and patterns. After dynamically sized types, this syntax is
the last remnant of the strange parser behavior by which the parser does
something different
Would it be worth introducing an own!() macro for this purpose? I came
across this suggestion on the reddit thread:
http://www.reddit.com/r/rust/comments/2340zb/rustdev_removing_foo/
--
Ziad
On Tue, Apr 15, 2014 at 10:12 AM, Patrick Walton pcwal...@mozilla.comwrote:
Hi everyone,
I'd like to
On 15/04/14 04:28 PM, Ziad Hatahet wrote:
Would it be worth introducing an own!() macro for this purpose? I came
across this suggestion on the reddit
thread: http://www.reddit.com/r/rust/comments/2340zb/rustdev_removing_foo/
--
Ziad
I think using the term own for that would greatly
On 15/04/14 09:20 PM, Tommi wrote:
Disclaimer:
I don't know the current status of 'assert' macro, but for the duration of
this post I'll assume that it's going to change into a sanity-checking tool
and will get compiled away in release builds. I'll also assume that there
will be a macro
Similar to what Daniel said, I don't think this works nicely unless all
possible calls to foo are enclosed with this keyword. The code for enforce!
would be part of foo, and called from multiple locations. If some disable
it and some don't, then what?
In general, I'd be against allowing
Could you provide a code sample that causes this error?
On Tue, Apr 15, 2014 at 6:28 AM, Artella Coding
artella.cod...@googlemail.com wrote:
Currently if I try to specify lifetimes in the return types of overloaded
operators like Index ([]), I get an error message :
method `index` has an
On 2014-04-16, at 4:34, Daniel Micay danielmi...@gmail.com wrote:
On 15/04/14 09:20 PM, Tommi wrote:
Disclaimer:
I don't know the current status of 'assert' macro, but for the duration of
this post I'll assume that it's going to change into a sanity-checking tool
and will get compiled away
On 2014-04-16, at 4:39, Brandon Sanderson singingb...@gmail.com wrote:
In general, I'd be against allowing disabling of something like 'enforce!'.
The whole point of using such a macro would be to say Never let this be
false. If it is, fail so that it can't cause bigger problems. Your
On Tue, Apr 15, 2014 at 1:12 PM, Patrick Walton pcwal...@mozilla.com wrote:
Hi everyone,
I'd like to remove the `~foo` literal syntax for owned strings in both
expressions and patterns. After dynamically sized types, this syntax is the
last remnant of the strange parser behavior by which the
20 matches
Mail list logo
