[swift-evolution] Pitch: Improved Swift pointers

[Taylor Swift]

On Tue, Jul 18, 2017 at 5:20 PM, Taylor Swift <kelvin13ma at gmail.com> wrote:

> 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
>>
>
>
It doesn’t look like there’s an equivalent subtyping relationship between
UnsafeMutableBufferPointer and UnsafeBufferPointer like there is between
the plain pointers. I agree this should be solved in the compiler.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170718/78179eb3/attachment.html>