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

[Andrew Trick]

Thanks for reviewing!

> On Jun 30, 2016, at 9:37 AM, Guillaume Lessard via swift-evolution <swift-evolution at swift.org> 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
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution