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

Reply via email to