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

[Taylor Swift]

On Thu, Sep 7, 2017 at 1:33 PM, Jordan Rose <jordan_rose at apple.com> wrote:

>
>
> 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.
>

assign(to:) was never part of the original proposal, now that you mention
it, it’s stupid and should be left out
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170907/70648e6d/attachment.html>