On Tue, Jul 18, 2017 at 5:20 PM, Taylor Swift <kelvin1...@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 <atr...@apple.com> wrote: > >> >> On Jul 18, 2017, at 11:36 AM, Taylor Swift <kelvin1...@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.
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution