> https://github.com/apple/swift-evolution/blob/master/proposals/0176-enforce-exclusive-access-to-memory.md
> What is your evaluation of the proposal? It's a bit hard to evaluate without experience. But I would summarize the benefits like this: 1. Clearer semantics inside functions. Variables that can alias each other makes things hard to reason about. Generally, this we just disregard the possibility of this happening. Having the language guard against this is going to make it easier to reason about the effects of the code. 2. Better optimizations. Variable that can alias each other force the optimizer to be pessimistic. All that to support cases that probably weren't well though out when the code was written because the semantics are hard to follow. I find the first point about clearer semantics most interesting. > Is the problem being addressed significant enough to warrant a change to > Swift? Looks like something that should be done. Swift already disallows that I think, but it only checks for the obvious cases. Providing guaranties about exclusivity opens the road to a lot of useful things for future evolution of the language. > Does this proposal fit well with the feel and direction of Swift? Given that the alternative option to dynamic checking is to have a complex set of annotations to track everything statically, I think the proposed approach makes sense. If I understand well however, allowing the optimizer to be more optimistic about exclusivity is going to be make memory corruption more likely in cases the exclusivity rule is violated for types that contain pointers. I'm thus a bit weary of the idea of disabling the runtime checks in production by default while at the same time enabling the optimizations that depends on this unverified exclusivity. > If you have used other languages or libraries with a similar feature, how do > you feel that this proposal compares to those? This reminds me of `restrict` in C, which can be dangerous if used incorrectly. Having a checking mechanism for exclusivity removes those concerns. https://en.wikipedia.org/wiki/Restrict > How much effort did you put into your review? A glance, a quick reading, or > an in-depth study? Read the ownership manifesto, the proposal, the discussion about the proposal. -- Michel Fortin https://michelf.ca _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
