On Wed, Apr 2, 2014 at 9:21 PM, Daniel Micay danielmi...@gmail.com wrote:
I used a sentinel value in my fix along with providing a guarantee that
`free` is never called on zero-size allocation. That's the end of any
no-op `VecT` - `~[T]` conversions since it will need to free a zero
size
On 03/04/14 17:15, comex wrote:
You're talking about allocators designed around the limitation of an
API. The design no longer needs to make the same compromises if you're
going to know the size. The difference between no cache miss and a cache
miss is not insignificant...
I explained why I
On 03/04/14 02:15 AM, comex wrote:
On Wed, Apr 2, 2014 at 9:21 PM, Daniel Micay danielmi...@gmail.com wrote:
I used a sentinel value in my fix along with providing a guarantee that
`free` is never called on zero-size allocation. That's the end of any
no-op `VecT` - `~[T]` conversions since it
On Wed, Apr 02, 2014 at 09:21:56PM -0400, Daniel Micay wrote:
...A distinct `~[T]` and `VecT` will make the language more
painful to use...
This is precisely the matter of debate, isn't it? I personally see two
sides to this, which is why I was suggesting that maybe we should wait
until we can
On 03/04/14 10:22, Niko Matsakis wrote:
On Wed, Apr 02, 2014 at 04:03:37PM -0400, Daniel Micay wrote:
I have no sane proposal to fix this beyond passing a size to free.
I don't believe there is a problem with just not using null to
represent such pointers (for example, 1 would suffice). This
In terms of making hello world nice in 0.10, I prefer to simply put
something else in the format string in order to clarify what the first
argument is there for:
fn main() {
let x = world;
println!(Hello, {:s}!, x);
}
Also remember that saying `println!(Hello, world!);`
On 03/04/14 01:22 PM, Ziad Hatahet wrote:
Would it be useful to look at what other languages are doing? For
instance, slices in Go are appendable, so perhaps it would be worth
looking at code bases written in Go to see how they deal with slices, or
how often they append to slices returned from
Mozilla and the Rust community are pleased to announce version 0.10 of the
Rust compiler and tools. Rust is a systems programming language with a
focus on safety, performance and concurrency.
This was an exciting release cycle where we broke apart the libextra
library, introduced cross-crate
On Thu, Apr 3, 2014 at 11:09 AM, Daniel Micay danielmi...@gmail.com wrote:
Go doesn't have an equivalent to what `~[T]` will be.
Which was my point. From what I understand, Go's slices are analogous to
Rust's VecT in that they are growable. So I was suggesting perusing
existing Go code bases
On 03/04/14 03:43 PM, Ziad Hatahet wrote:
But `println!(hello world)` works. What am I missing?
--
Ziad
It works when there's a string constants, not with a variable.
signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing
I have a suggestion. Let's add new primitive data types:
i7, i15, i31, i63, u7, u15, u31, u63, f31 and f63
Those would behave exactly like the integral data and floating-point data types:
i8, i16, i32, i64, u8, u16, u32, u64, f32 and f64
...except that the new data types would come with the
I forgot to mention that this same space-optimization could be done for
Optionbool already.
On 2014-04-04, at 03:18, Tommi rusty.ga...@icloud.com wrote:
I have a suggestion. Let's add new primitive data types:
i7, i15, i31, i63, u7, u15, u31, u63, f31 and f63
Those would behave exactly
Language suggestions should go through our new RFC process:
https://github.com/rust-lang/rfcs/blob/master/active/0001-rfc-process.md
On Thu, Apr 3, 2014 at 8:26 PM, Tommi rusty.ga...@icloud.com wrote:
I forgot to mention that this same space-optimization could be done for
Optionbool already.
Perhaps the best thing is to wait a month (or two or three) until DST
is more of a reality and then see how we feel.
Are you thinking we should also wait before converting the current uses
of ~[T] to VecT? Doing the migration gives us the performance[1] and
zero-length-zero-alloc benefits,
+1 for printf! and printfln!
2014年4月3日 下午1:14于 Daniel Micay danielmi...@gmail.com写道:
Perhaps we should have `print` and `println` back in the prelude and
call these `printf!` and `printfln!`. I think it would be a lot clearer,
as people always ask how these are different from `print` and
15 matches
Mail list logo