[swift-evolution] [swift-evolution-announce] [Review] SE-0107: UnsafeRawPointer API

[Guillaume Lessard]

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