I am planning to submit a PR changing this so that we have no need of
zeroing memory out. This does mean that some programs which today are
legal will become illegal, because the compiler must know
unambiguously at each point what is to be freed: in other words, if
one path of an if/else consumes
On 11/14/2013 01:08 PM, Daniel Glazman wrote:
Honestly, I am not sure tutorial quality and automatic generation live
well together. We hire tech evangelists for their ability to present well
information and make messages percolate better, and similarly good doc
requires good tech writers who
On 11/15/2013 06:24 AM, Gaetan wrote:
I would love a documentation Rust for Pythonist or Rust for C++'iste.
I don't like the Wiki page. I think the official documentation
homepage should be a nice, beautiful http://doc.rust-lang.org/
http://static.rust-lang.org/. Period.
It should link all
I ve started the github project now i just need to learn rust...
https://github.com/Stibbons/rust-for-pythonists
Le 18 nov. 2013 21:10, Brian Anderson bander...@mozilla.com a écrit :
On 11/15/2013 06:24 AM, Gaetan wrote:
I would love a documentation Rust for Pythonist or Rust for C++'iste.
Hi all,
I'm a newcomer to Rust. One of the things that I find confusing is the use
of {} in formatted strings. In all other languages I've ever used, it's
always %. So instead of writing %d, you write {:d} in Rust. Why is
this so? What benefits do we get?
Thanks,
Derek
On 11/13/13 2:37 AM, Greg wrote:
1. ~[OptionBucketK,V]
2. fn linear_map_with_capacityK:Eq + Hash,V(capacity: uint) -
LinearMapK,V
3. fn contains_key(self, k: K)
My approach would be to try and get rid of templates through better
type inference in the compiler.
We need the ability to
On Mon, Nov 18, 2013 at 2:02 AM, Derek Chiang derekchian...@gmail.com wrote:
Hi all,
I'm a newcomer to Rust. One of the things that I find confusing is the use
of {} in formatted strings. In all other languages I've ever used, it's
always %. So instead of writing %d, you write {:d} in
Rust’s old fmt! syntax also used % instead of {}. The reason for the switch was
to primarily support compatibility with an internationalization-style scheme of
string formatting. The main benefit of {} of % is that you can nest {} inside
of another format, whereas with % you’re limited to just
On 11/17/2013 11:30 AM, David Renshaw wrote:
Hi everyone.
I wrote up some of my latest experiences implementing Cap'n Proto
encoding for Rust.
A performance comparison to C++, or capnproto-rust is pretty fast:
http://dwrensha.github.io/capnproto-rust/2013/11/16/benchmark.html
A discussion
Hello folks,
I have been thinking of working on an editor agnostic code helper library
with an autocomplete engine for rust (since there isn't anything yet?) as a
hobby project to get to know the internals of the compiler. Examples of
similar projects in different languages include;
-
On 11/15/2013 05:03 PM, Diego Ongaro wrote:
On Thu, Nov 14, 2013 at 5:19 PM, Brian Anderson bander...@mozilla.com wrote:
On 11/14/2013 04:03 PM, Diego Ongaro wrote:
My program starts a bunch of tasks, then I want the main task to both
receive ctrl-c signals and receive results from the
...and possibly change `~`.
To what?
--
Ziad
On Tue, Nov 12, 2013 at 1:31 PM, Patrick Walton pcwal...@mozilla.comwrote:
On 11/13/13 2:37 AM, Greg wrote:
1. ~[OptionBucketK,V]
2. fn linear_map_with_capacityK:Eq + Hash,V(capacity: uint) -
LinearMapK,V
3. fn contains_key(self, k: K)
On 11/18/13 4:23 PM, Ziad Hatahet wrote:
...and possibly change `~`.
To what?
`*`
Patrick
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
On 11/15/2013 12:09 AM, Alex Crichton wrote:
I've been thinking about static linking recently, along with a little bit of
linking in general, and I wanted to see what others thought.
# The Goal
Primarily, I believe that if desired, rustc should be able to generate an
executable or dynamic
On 11/15/2013 03:01 AM, Niko Matsakis wrote:
A few quick questions and comments:
On Fri, Nov 15, 2013 at 12:09:28AM -0800, Alex Crichton wrote:
As a side node, after writing all this up, I remembered LTO as an
option for generating libraries. I don't think I know enough about LTO
to be able to
On 11/15/2013 03:01 AM, Niko Matsakis wrote:
A few quick questions and comments:
On Fri, Nov 15, 2013 at 12:09:28AM -0800, Alex Crichton wrote:
I've been thinking about static linking recently, along with a little bit of
linking in general, and I wanted to see what others thought.
# The Goal
To what?
`*`
...But only if you change the deref operator to something else.
Bikeshedding thread! :P
On Mon, Nov 18, 2013 at 7:27 PM, Patrick Walton pcwal...@mozilla.comwrote:
On 11/18/13 4:23 PM, Ziad Hatahet wrote:
...and possibly change `~`.
To what?
`*`
Patrick
On 11/18/13 5:33 PM, Benjamin Striegel wrote:
To what?
`*`
...But only if you change the deref operator to something else.
Bikeshedding thread! :P
No, allocation would be with `new`.
Patrick
___
Rust-dev mailing list
Rust-dev@mozilla.org
On 11/18/2013 04:27 PM, Patrick Walton wrote:
On 11/18/13 4:23 PM, Ziad Hatahet wrote:
...and possibly change `~`.
To what?
`*`
Also, s/fn/fun/g
We must not underestimate the importance of being perceived as a
fun language.
C++ is a general purpose programming language designed to make
* #[link(...)] becomes the new method of specifying linkage semantics on
extern
blocks, and it may be used similarly to link_args today
I'd kind of like for this to be available at the crate level too since most
libraries don't use OS X two-level namespaces and it's more convient to me
On Mon, Nov 18, 2013 at 5:34 PM, Patrick Walton pcwal...@mozilla.comwrote:
No, allocation would be with `new`.
Would that have to proceed each allocation? For instance, would
let v = ~[~one, ~two, ~three];
turn into
let v = new Vector(new one, new two, new three);
?
--
Ziad
Yes.
Patrick
Ziad Hatahet hata...@gmail.com wrote:
On Mon, Nov 18, 2013 at 5:34 PM, Patrick Walton
pcwal...@mozilla.comwrote:
No, allocation would be with `new`.
Would that have to proceed each allocation? For instance, would
let v = ~[~one, ~two, ~three];
turn into
let v = new
Keep in mind that, IMHO, the brevity of ~ is a large reason why people
overallocate and make Rust programs slower than they need to be (e.g. your
example).
Patrick
Patrick Walton pwal...@mozilla.com wrote:
Yes.
Patrick
Ziad Hatahet hata...@gmail.com wrote:
On Mon, Nov 18, 2013 at 5:34 PM,
On Tue, Nov 19, 2013 at 11:13 AM, Brian Anderson bander...@mozilla.comwrote:
Of course this conflicts with the `link` attribute of crates, which I
think is poorly named anyway.
Perhaps #[link] in its current usage should be renamed to #[crate]? I think
that would make more sense.
He said IMHO ..
An explicit new is a huge indicator of what is going on ... most people
are familiar enough with stack allocation early adopters are not 9-5
developers..
Ben
On Tue, Nov 19, 2013 at 11:41 AM, Kevin Ballard ke...@sb.org wrote:
Is that really why, or are you just guessing? I'm
On 11/18/13 7:41 PM, Kevin Ballard wrote:
Is that really why, or are you just guessing? I'm assuming the real
reason is that people are used to languages where heap allocation is
common and stack allocation rare or nonexistant, and don't understand
why boxing everything is a bad idea. In other
I tend to agree with this, think that a collaborative approach is unlikely
to produce a consistent and high quality tutorial. I don't want to
discourage anybody but my current opinion is that we should hire an
experienced technical writer to do this piece especially, with input from
the
27 matches
Mail list logo
