[swift-evolution] Pitch: Replace UnsafeMutablePointer by UnsafePointer in non-mutating APIs

Xiaodi Wu xiaodi.wu at gmail.com
Tue Jul 19 16:57:09 CDT 2016


Is this limited to auditing the stdlib only or other APIs as well with
Swift overlays/API notes?
On Tue, Jul 19, 2016 at 16:47 Arnold Schwaighofer via swift-evolution <
swift-evolution at swift.org> wrote:

> # Replace `UnsafeMutablePointer` by `UnsafePointer` in non-mutating APIs
>
> * Proposal: [SE-0000](
> 0000-change_unsafe_mutable_pointer_to_unsafe_pointer.md)
> * Author: [Arnold Schwaighofer](https://github.com/aschwaighofer)
> * Status: **Pitch**
> * Review manager: TBD
>
> ## Introduction
>
> `UnsafeMutablePointer` didn't always have an immutable variant, and when
> it was
> introduced there could have been many places that should have been changed
> to
> use it, but were not. `UnsafeMutablePointer` is still pervasive. We should
> survey the uses and make sure they're all using mutability only as
> appropriate.
>
> The only such occurrence I found was the `dprintf` API which should have a
> read-only format argument.
>
> - Swift bug: [SR-1958] (https://bugs.swift.org/browse/SR-1958)
> - Branch with changes to stdlib:
> [unsafe_mutable_pointer_to_unsafe_pointer] (
> https://github.com/aschwaighofer/swift/tree/unsafe_mutable_pointer_to_unsafe_pointer
> )
>
> ## Motivation
>
> We should change uses of `UnsafeMutablePointer` with `UnsafePointer` to
> clearly
> express the intent of the API where appropriate.
>
> ## Proposed solution
>
> The proposed solution is to change `dprintf` API to take a `UnsafePointer`
> argument.
>
> ## Detailed design
>
> Change:
> ```swift
> public func dprintf(_ fd: Int, _ format: UnsafeMutablePointer<Int8>, _
> args: CVarArg...) -> Int32
> ```
>
> To
> ```swift
> public func dprintf(_ fd: Int, _ format: UnsafePointer<Int8>, _ args:
> CVarArg...) -> Int32
> ```
> ## Impact on existing code
>
> Existing coersions to `UnsafePointer` from `UnsafeMutablePointer` will
> allow
> existing code to work.
>
> ## Alternatives considered
>
> Leave as is.
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160719/387db807/attachment.html>


More information about the swift-evolution mailing list