Re: [rust-dev] alias analysis

2011-06-07 Thread Marijn Haverbeke
I committed a patch yesterday that I thought was a very good first start. However, this morning I've found some holes in it that make things look very bleak again. What my patch did was simply ensure one thing -- that whenever an alias was taken, it was verified that it was 'rooted' in a thing

Re: [rust-dev] alias analysis

2011-06-07 Thread Patrick Walton
On 6/7/11 12:59 AM, Marijn Haverbeke wrote: Unfortunately, there's this hole I mentioned before. What this analysis guarantees is that the location pointed to by an alias will always hold a value of type X — if you reassign to it, the alias will still be valid. Except when going through a tag

Re: [rust-dev] alias analysis

2011-06-07 Thread Marijn Haverbeke
Sorry if I'm misunderstanding, but I thought I covered that in my previous email--we have to forbid access to the expression in an alt statement inside the case blocks. Your proposal seems to assume you'd only ever directly alias locals. That is a possible solution, but it seems excessively

Re: [rust-dev] alias analysis

2011-06-07 Thread Graydon Hoare
On 07/06/2011 7:40 AM, Marijn Haverbeke wrote: Sorry if I'm misunderstanding, but I thought I covered that in my previous email--we have to forbid access to the expression in an alt statement inside the case blocks. Your proposal seems to assume you'd only ever directly alias locals. That is a

Re: [rust-dev] alias analysis

2011-06-07 Thread Graydon Hoare
On 11-06-07 01:05 PM, Florian Weimer wrote: AFAICS, Ada has a somewhat similar issue (the affected types have discriminants with defaults). Over there, the prevalent feeling seems to be that destructive update of objects of types with discriminants with defaults is to blame, and not aliasing.

Re: [rust-dev] alias analysis

2011-06-07 Thread David Herman
Indeed. This was always going to be one of the trickiest part of the design. In this latest iteration, we've only been attacking it for a couple of days. We can't expect a solution to just pop out that easily; we will have to bang our heads against it for a while. And we've already seen a

Re: [rust-dev] alias analysis

2011-06-04 Thread Marijn Haverbeke
(1) Handing out aliases to local variables and function parameters (directly, not substructures thereof) is always safe. The calling function is the only one that can possibly provide access its own locals, and it's suspended for the duration of the call. Except for upvars. 'for each' bodies

Re: [rust-dev] alias analysis

2011-06-03 Thread Graydon Hoare
On 03/06/2011 7:29 AM, Marijn Haverbeke wrote: [This is just a rambing e-mail outlining some problems I'm running into. Though I am stressing these problems to make sure they are not glossed over, I'm *not* suggesting we give up aliases or anything like that.] Much appreciated; if something's

Re: [rust-dev] alias analysis

2011-06-03 Thread Graydon Hoare
On 11-06-03 01:51 PM, Patrick Walton wrote: Thoughts? I like the line of reasoning; let me try phrasing in a slightly more terse/pithy fashion: Alias-formation must preserve unique ownership of the referent IOW an alias is assumed to be a form of unique access to its immediate referent

Re: [rust-dev] alias analysis

2011-06-03 Thread Patrick Walton
On 6/3/11 2:07 PM, Graydon Hoare wrote: On 11-06-03 01:51 PM, Patrick Walton wrote: Thoughts? I like the line of reasoning; let me try phrasing in a slightly more terse/pithy fashion: Alias-formation must preserve unique ownership of the referent Right, that's a good way to put it.