On 7/14/11 8:23 PM, Marijn Haverbeke wrote:
makes
me wonder if it's worth the complexity of aliasing into patterns as opposed
to having pattern matching bindings simply copy
Copying is expensive for a lot of types, sometimes even illegal. I'm
not opposed to having a syntax for copying alt match
> makes
> me wonder if it's worth the complexity of aliasing into patterns as opposed
> to having pattern matching bindings simply copy
Copying is expensive for a lot of types, sometimes even illegal. I'm
not opposed to having a syntax for copying alt matches, but I think
aliasing should remain th
On 11-07-13 02:12 PM, Michael Sullivan wrote:
I like this solution because I think it effectively captures a really handy use of blocks
without needing add much "magic" or special cases. In particular, I think that
making it explicit gives us a good method for forcing the return of a value fro
I have the following code working (if you disable typestate) in my half-working
lambdas branch (https://github.com/msullivan/rust/tree/incur-capture):
// I think that this is actually pretty workable as a scheme for using
// blocks to affect control flow. It is a little syntactically heavyweight
On 7/14/11 12:11 PM, Graydon Hoare wrote:
I disagree. The delete is the prohibited bit (by type-based interference
with *h1; best the compiler can do due to the id() call it can't see
through). Accessing &val in a read-only sense should be safe.
Okay, I see what you mean. I'm a bit concerned ab
We've just bumped LLVM version again. You'll all want to upgrade. This
is the "new LLVM type system" which I think is the cornerstone of LLVM 3.0.
Upgrade to 135178 or later.
(Hopefully we'll be able to pin to, say, 3.0 for some time, once it's
released. Hope hope.)
-Graydon
On 11-07-14 12:59 PM, Marijn Haverbeke wrote:
Disallows ... on the *caller* side as well?
Of course -- otherwise it would be unsafe.you could call a function
that gave you an alias to the internals of a local, and then trash
that local and keep on using the alias.
Yeah. That's sorta my concer
> Disallows ... on the *caller* side as well?
Of course -- otherwise it would be unsafe.you could call a function
that gave you an alias to the internals of a local, and then trash
that local and keep on using the alias.
> How far out can the alias go?
I guess you mean returning through multiple
On 11-07-14 12:44 PM, Marijn Haverbeke wrote:
I don't understand how the alias checker figures into it. It's a lifetime
thing. How do you ensure the aliased value remains live as long as the alias
does?
Right, I was too vague on that. You can only return aliases that are
'rooted' (by the rules
> I don't understand how the alias checker figures into it. It's a lifetime
> thing. How do you ensure the aliased value remains live as long as the alias
> does?
Right, I was too vague on that. You can only return aliases that are
'rooted' (by the rules I explained in the previous alias-checking
> let h1 = @hashmap::mk();
> let h2 = id(h1); // identity fn; compiler can't see through this
> hashmap::insert(*h1, "foo", "bar");
> hashmap::get(*h1, "foo", { |&val|
> hashmap::delete(h2, "foo");
> print val; // crash
> });
The alias checker would yell at you for the hashmap::delet
On 11-07-07 10:17 AM, Lindsey Kuper wrote:
It's been suggested that we start by splitting trans into two pieces. The
first would be, more or less, all the trans_X() functions where 'X' is
recognizably something in the AST, and the second would be everything else:
support functions, glue, LLV
On 11-07-14 10:34 AM, Patrick Walton wrote:
After the conversation among Dave, Dan Grossman, and me yesterday, I
actually think that we don't want "accessing things through blocks" at
all. I believe it's impossible to make memory-safe. Consider:
let h1 = @hashmap::mk();
let h2 = id(h1); // iden
On 11-07-14 03:08 AM, Marijn Haverbeke wrote:
First, a relatively non-controversial case:
auto&ccx = cx.fcx.lcx.ccx; // Look ma, no refcounting bumps!
This case is very similar to alt/for blocks, and the alias checker
could check it with a relatively simple extension.
Next, of couse, I'm goi
Made a mistake with #iter. It should be:
alt (e) {
f_normal { }
f_break | f_continue { fail; }
f_return(?x) { return x; }
}
- Original Message -
> There are approximately 549839483286534 interrelated sub-issues
> currently complicating figuring out how we want to treat
> functions/cl
On 7/14/11 3:08 AM, Marijn Haverbeke wrote:
First, a relatively non-controversial case:
auto&ccx = cx.fcx.lcx.ccx; // Look ma, no refcounting bumps!
This case is very similar to alt/for blocks, and the alias checker
could check it with a relatively simple extension.
Next, of couse, I'm going
On 11-07-14 6:08 AM, Marijn Haverbeke wrote:
First, a relatively non-controversial case:
auto&ccx = cx.fcx.lcx.ccx; // Look ma, no refcounting bumps!
This case is very similar to alt/for blocks, and the alias checker
could check it with a relatively simple extension.
Next, of couse, I'm goin
First, a relatively non-controversial case:
auto &ccx = cx.fcx.lcx.ccx; // Look ma, no refcounting bumps!
This case is very similar to alt/for blocks, and the alias checker
could check it with a relatively simple extension.
Next, of couse, I'm going to argue that 'accessing things through
bloc
18 matches
Mail list logo
