>> * 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. - 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. >> * 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
