Hi Rust team! First of all, congratulations on the 0.3 release!
I have a bikeshed proposal to selectively simplify Rust's syntax in a
way that has the side benefit of applying negative syntactic
pressure on expensive constructs. It boils down to this: remove all
special syntax for heap
On 13/07/12 05:26, Zack Corr wrote:
On Fri, Jul 13, 2012 at 2:44 AM, David Brown dav...@davidb.org
mailto:dav...@davidb.org wrote:
On x86_64 Arch Linux, I get the error log below. Interestingly, if I
just type make again, it builds what appears to be a perfectly
functional rustc.
On 12/07/2012 7:42 PM, Tim Chevalier wrote:
It's easier for each person to be responsible for running make check
than for every person to potentially have to untangle a mess of
commits from everybody else before making a small amount of progress.
Agreed. With the exception of Extenuating
Hello Rustics,
Per recent discussions, I would very much like to remove code related to
typestate. It seems that the current approach is not scaling up to real
problems. There has been some discussion about alternative,
lighterweight approaches. I am not opposed to such forward motion.
On 07/13/2012 09:04 AM, Niko Matsakis wrote:
Hello Rustics,
Per recent discussions, I would very much like to remove code related to
typestate. It seems that the current approach is not scaling up to real
problems. There has been some discussion about alternative,
lighterweight approaches. I am
Le 11/07/2012 03:05, Brian Anderson a écrit :
On 07/10/2012 12:13 PM, David Bruant wrote:
(...)
Tasks do have a memory cost, but it is theoretically quite low. Rust
tasks on linux currently have somewhere around 4K of overhead, and
that's around 3K more than we would like and think is
Hi,
Looking at the Rust documentation, I read:
Named functions, like those we've seen so far, may not refer to local
variables decalared outside the function - they do not close over their
environment. For example you couldn't write the following:
let foo = 10;
fn bar() - int {
ret foo;
On 7/13/12 12:38 PM, David Bruant wrote:
I can't help but asking why can't named function close over their
environment?
In the case above, I see no harm in allowing the 'bar' function to
access 'foo'.
Because named functions are always in scope (they're always mutually
recursive), while
Le 13/07/2012 21:42, Patrick Walton a écrit :
On 7/13/12 12:38 PM, David Bruant wrote:
I can't help but asking why can't named function close over their
environment?
In the case above, I see no harm in allowing the 'bar' function to
access 'foo'.
Because named functions are always in scope
rust currently has support for vectors allocated on the task-local
heap (@[]s), but the support is essentially limited to creating
@-vector literals and indexing into them. There is currently no other
method of creating them. I've thought some about this, and I've
collected my thoughts:
* I want
I think the situation is somewhat more complex than you suggest.
First, heap-based closures like fn@ and fn~ copy values from the
environment at the point of creation. This is particularly relevant for
mutable variables. To allow for mutual recursion, we would need some
sort of expression
On 07/13/2012 11:58 AM, David Bruant wrote:
Le 11/07/2012 03:05, Brian Anderson a écrit :
On 07/10/2012 12:13 PM, David Bruant wrote:
(...)
Tasks do have a memory cost, but it is theoretically quite low. Rust
tasks on linux currently have somewhere around 4K of overhead, and
that's around 3K
On 12-07-13 9:47 AM, Niko Matsakis wrote:
On 7/13/12 9:20 AM, Patrick Walton wrote:
What function preconditions remain? My understanding was that there
weren't any in the Rust compiler and standard libraries...
I think the only ones that remain are two in core::result and some in
tests.
On 12-07-13 1:44 PM, Michael Sullivan wrote:
An example of some code that could use it:
// Some code that could use that, then:
fn seq_range(uint lo, uint hi) - @[uint] {
do construct() |push| {
for range(lo, hi) |i| {
push(i);
}
}
}
The critical
On Fri, Jul 13, 2012 at 5:18 PM, Graydon Hoare gray...@mozilla.com wrote:
Thus ~T becomes uniqT, ~expr becomes uniq(expr), etc?
Yep.
Allocating a block of
uninitialized memory of type T might be heap_allocT(), with the
normal literals used to initialize it.
Note: we don't support
15 matches
Mail list logo
