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 number of creative and promising ideas.
FWIW, I have a pretty good feeling that we're going to converge on something reasonable. Not perfect, but reasonable. Patience, everyone -- we'll get there! Dave On Jun 7, 2011, at 2:10 PM, Graydon Hoare wrote: > 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. >> Nevertheless, the language contains fairly complex rules which prevent >> obviously dangerous creation of aliases, but already Ada 83 gave up on >> dealing with aliased subprogram arguments, shifting responsibility to >> the programmer. > > Yeah. The story of Ada's not-quite-right approaches to memory-safe aliasing > have always weighed heavily on my mind. The Ada rationale glares at me from > my bookcase every night. > > In case anyone's got any illusions that this is some kind of a "new thing" I > was surprised to run across: I've long known there was going to be an ugly > set of cases here requiring a lot of delicate arrangement-of-pieces. I > convinced myself that there was enough permutation-space in the design > landscape, and enough instability in other parts of the memory model, that I > wasn't going to be able to nail down the aliasing rules for most of this > early development period. Too much has been in flux (copy-on-write, GC, > layer/kind system, uniqueness guarantees, typestate system, mutability > representation, temporaries from expression-evaluation, etc. etc.) > > But I've worried about it nonetheless, and regularly returned to sketch > possibilities and try to convince myself we hadn't doomed all possible > solutions yet; been dreading this bug rising to "blocking" status since well > before firefox *2* shipped. This is probably my biggest area of concern in > the whole language. So if we can hold fast at the level of complexity of the > rules I outlined a couple messages ago in this thread, I'll be deliriously > happy and relieved. > > Please don't consider that level of complexity a failure. Anything we can > summarize in that "small" a list of rules, cases and runtime checks would be > a *total success*. > > -Graydon > _______________________________________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/rust-dev _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
