[swift-evolution] [swift-evolution-announce] [Review] SE-0107: UnsafeRawPointer API
glessard at tffenterprises.com
Thu Jun 30 11:37:15 CDT 2016
>> * 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?
>> * 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.
More information about the swift-evolution