[swift-evolution] [Draft] UnsafeRawPointer API

[Dmitri Gribenko]

Hi Andy,

Thank you for the proposal!  A few comments from me.

- In the "Custom memory allocation section" you write:

> Note: The same allocated raw memory cannot be used both for this custom memory allocation case and for the C buffer case above because the C buffer requries that the allocated raw memory is always initialized to the same type.

Could you provide more explanation?  I'm not quite getting it.  Is
this because of binding -- are you saying that there is no way to
un-bind the type?

- In the "Accessing uninitialized memory with a typed pointer (binding
the type)" section you write

> This cast explicitly signals the intention to bind the raw memory to the destination type.

I think that "signals the intention" is not a strong enough wording,
it is open to interpretations.  Either it is a no-op "intention" (that
can be retracted) or it is the actual binding.  From other discussions
in this thread, I think you are proposing that the .toType() method
actually binds the memory to a type.  Is this right?  Here's what made
me think this way:

> The following code is undefined:
> ```
> ptrA = rawPtr.cast(to: UnsafePointer<A>.self)
> ptrA.initialize(with: A())
> ptrA.deinitialize()
> ptrB = rawPtr.cast(to: UnsafePointer<B>.self)
> ptrB.initialize(with: B())
> ```
> It is hard to spot the difference between the two styles without drawing attention to the unsafe cast.

- In the same section, in the table, it is not clear whether the
"tptr.deinitialize" operation un-binds the memory type, or does not
have effect on it.  Which way is it?  Can I replace
"tptr.initialize(t2: T)" with "tptr.initialize(u1: U)"?

- Is it valid to access an ARC reference to a class MyClass that
conforms to MyProtocol with aliasing pointers,
UnsafeMutablePointer<MyClass>, UnsafeMutablePointer<MyProtocol>, and
'UnsafeMutablePointer<AnyObject>' ?  What about
'UnsafeMutablePointer<AnyObject?>' ?

- There's no API to convert from UnsafeMutableRawPointer to
UnsafeMutablePointer<T> without either doing an initialization, or
binding the type.  Is this on purpose?  The reason why I'm asking is
that initialization does not seem to be binding the type (I couldn't
find that in the proposal), but still performs the conversion,
allowing further code to use typed memory access.  If this allows the
optimizer to get the desired guarantees about memory, why is binding
important?  (I'm probably completely confused about this point.)

- Just wanted to mention that we'd probably need 'raw' variants of
atomic operations for stdlib-internal use, but you probably already
noticed that while working on the branch.

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/