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 <[email protected]> wrote: > > On Jul 18, 2017, at 11:36 AM, Taylor Swift <[email protected]> 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 >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
