[swift-evolution] Pitch: Improved Swift pointers

Taylor Swift kelvin13ma at gmail.com
Tue Jul 18 16:20:12 CDT 2017

No, I just forgot about the compiler subtyping relationship. Never mind
that part then lol

On Tue, Jul 18, 2017 at 4:40 PM, Andrew Trick <atrick at apple.com> wrote:

> On Jul 18, 2017, at 11:36 AM, Taylor Swift <kelvin13ma at gmail.com> wrote:
> I'm not sure removing the need for implicit casts is a goal. I did
>> that with the pointer `init` methods, but now I think that should be
>> cleaned up to reduce API surface. I think smaller API surface wins in
>> these cases. Is there a usability issue you're solving?
> Yes, I can imagine initializing a mutable pointer to some values, and then
> wanting to use that pointer as a source to initialize more buffers. Having
> to convert a mutable pointer to an immutable pointer is annoying because a
> function that takes an immutable pointer obviously shouldn’t care if the
> pointer could be mutated anyway. It’s like having to rebind a `var`
> variable to a `let` constant before passing it as any non-inout argument
> to a function, since function parameters are immutable. At any rate, this
> only applies to two out of the seven memorystate operations, so comparably,
> it’s not a big API expansion at all.
> The conversion you’re talking about should be handled by the compiler.
> public func get<T>(_ p: UnsafePointer<T>) -> T {
>   return p.pointee
> }
> public func foo<T>(p: UnsafeMutablePointer<T>) {
>   _ = get(p)
> }
> Or are you thinking of a different use case?
> -Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170718/790adb49/attachment.html>

More information about the swift-evolution mailing list