Thanks for reviewing! > On Jun 30, 2016, at 9:37 AM, Guillaume Lessard via swift-evolution > <[email protected]> wrote: > > >>> * What is your evaluation of the proposal? > > This is an excellent proposal, and a step forward in balancing safety and > un-safety in an understandable way. > > I have no issues about the substance, but two documentation issues: > > - the compiler’s strict aliasing rules: not clearly defined in this document. > I *think* I know mostly what that means, but I’m not completely sure.
That’s punted to a separate doc: For details of the compiler's rules for memory aliasing, see proposed Type Safe Memory Access documentation. https://github.com/atrick/swift/blob/type-safe-mem-docs/docs/TypeSafeMemory.rst That document needs to be rewritten now, but should be good enough for discussion. It’s important to focus on the source-breaking aspect of the proposal now. The memory model spec will be rewritten and clarified as we go. There’s just a limited bandwidth for people to review these kind of specs, and there are actually no changes to the strict aliasing rules being proposed here! I did recently add a simplified discussion about strict aliasing to the revised proposal, but it’s buried here: https://github.com/apple/swift-evolution/blob/master/proposals/0107-unsaferawpointer.md#initializing-memory-with-a-typed-pointer I should create a link at the top. > - so-called “trivial” types: > Coming from physics, where trivial means “not worthy of consideration” (an > English dictionary concurs.) > It made me wonder why integers deserved such a putdown; the word “simple” > would be just fine. > [y’ = y has solutions y(x) = e^x and y = 0; the latter is trivial as it > generally isn’t interesting, despite being valid.] > It’s probably meant as “easily proven”, but since no proofs are shown, it > feels like an inappropriate use. Point taken. That term is used throughout the implementation and was first officially documented here: https://github.com/apple/swift/blob/master/docs/SIL.rst#properties-of-types and again here: https://github.com/apple/swift/blob/master/docs/LibraryEvolution.rst#other-promises-about-types -Andy > >>> * Is the problem being addressed significant enough to warrant a change to >>> Swift? > > Absolutely. > >>> * Does this proposal fit well with the feel and direction of Swift? > > I think so. > >>> * If you have used other languages or libraries with a similar feature, how >>> do you feel that this proposal compares to those? > > I’ve only done the kind of things enabled by this in C/C++, where it just > feels like gambling. [feels like testing can only show that something works > on one particular C/C++ compiler]. Clarity is good. > >>> * How much effort did you put into your review? A glance, a quick reading, >>> or an in-depth study? > > I’ve followed this discussion from the start, and asked questions. My > interest was informed by experimental attempts to push the memory model; > those attempts would have been covered by this document. > > Cheers, > Guillaume Lessard > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
