Re: [rust-dev] Reminder: ~[T] is not going away

2014-04-03 Thread comex
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

Re: [rust-dev] Reminder: ~[T] is not going away

2014-04-03 Thread Huon Wilson
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

Re: [rust-dev] Reminder: ~[T] is not going away

2014-04-03 Thread Daniel Micay
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

Re: [rust-dev] Reminder: ~[T] is not going away

2014-04-03 Thread Niko Matsakis
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

Re: [rust-dev] Reminder: ~[T] is not going away

2014-04-03 Thread Huon Wilson
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

Re: [rust-dev] 0.10 prerelease testing

2014-04-03 Thread Benjamin Striegel
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!);`

Re: [rust-dev] Reminder: ~[T] is not going away

2014-04-03 Thread Daniel Micay
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

[rust-dev] Rust 0.10 Released

2014-04-03 Thread Alex Crichton
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

Re: [rust-dev] Reminder: ~[T] is not going away

2014-04-03 Thread Ziad Hatahet
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

Re: [rust-dev] 0.10 prerelease testing

2014-04-03 Thread Daniel Micay
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

[rust-dev] Tagged integral floating-point types

2014-04-03 Thread Tommi
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

Re: [rust-dev] Tagged integral floating-point types

2014-04-03 Thread Tommi
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

Re: [rust-dev] Tagged integral floating-point types

2014-04-03 Thread Corey Richardson
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.

Re: [rust-dev] Reminder: ~[T] is not going away

2014-04-03 Thread Nathan Myers
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,

Re: [rust-dev] 0.10 prerelease testing

2014-04-03 Thread Liigo Zhuang
+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