[swift-evolution] [Review] SE-0184: Unsafe[Mutable][Raw][Buffer]Pointer: add missing methods, adjust existing labels for clarity, and remove deallocation size

Jordan Rose jordan_rose at apple.com
Thu Sep 7 13:33:27 CDT 2017

> On Sep 5, 2017, at 14:50, Andrew Trick via swift-evolution <swift-evolution at swift.org> wrote:
> We don't have a consensus, but I think the suggestion to distinguish
> between single value vs. multiple semantics was good. Otherwise,
> adding the default count could be very misleading. Normally, we try to
> minimize surface area, but adding two methods for the single-value case
> avoids ambiguity between the buffer and pointer semantics:
> UMP (pointer)
> --- func initialize(to:count:(=1))
> +++ func initialize(to:)
> +++ func initialize(repeating:count:) // no default count
> +++ func assign(to:)
> +++ func assign(repeating:count:) // no default count
> UMRP (raw pointer):
> --- func initializeMemory<T>(as:at:(=0)count:(1)to:)
> +++ func initializeMemory<T>(as:repeating:count:) // remove default count

I am mostly in favor of this two-method approach, but 'to' may not be the right label. Today we have both initialize(to:…) and initialize(from:…), which are not opposites. I think we can live with that, but we definitely can't use assign(to:). "x.assign(to: y)" means some form of "y = x".

That said, we don't actually need a single-element 'assign' variant, because you can also write it "x.pointee = y". But I agree that symmetry is nice, if we can get it.

I also want to note that we don't get to remove any of the old signatures; we need to preserve them for compatibility with Swift 4.0 and Swift 3.0. They can be marked obsoleted in Swift 5 and even deprecated in Swift 4.1 if we feel strongly enough, but we don't get to drop them.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170907/966660d3/attachment.html>

More information about the swift-evolution mailing list