[swift-evolution] [Review] SE-0107: UnsafeRawPointer API (initialize:with:)

[Anton Zhilin]

func initialize<T>(_: T.Type, to: T, count: Int = 1)
    -> UnsafeMutablePointer<T>

I wonder why the first parameter is needed. If one is passing literals,
it's always more Swift'y to use 'as'.

2016-07-05 6:00 GMT+03:00 L. Mihalkovic via swift-evolution <
swift-evolution at swift.org>:

>
>
> Regards
> (From mobile)
>
> On Jul 3, 2016, at 10:18 AM, Andrew Trick via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>
> On Jul 2, 2016, at 8:10 PM, Brent Royal-Gordon via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> I have a pile of naming quibbles; rather than describe them all in prose
> (which turned into a mess), I've annotated parts of the "Full
> UnsafeRawPointer API" section in a gist: <
> https://gist.github.com/brentdax/8f4ed4decafc1d18c4441092baa13cfe>.
>
>
> Let's bikeshed this easy one now... I’m curious what others think:
>
>   // In general, I think you "initialize to" a value, not
>   // "initialize with" a value. "with" is needlessly vacuous.
>   //
>   // func initialize<T>(_: T.Type, with: T, count: Int = 1)
>   //   -> UnsafeMutablePointer<T>
>   func initialize<T>(_: T.Type, to: T, count: Int = 1)
>     -> UnsafeMutablePointer<T>
>
> `initialize` was recently renamed to `initialized(with:)`.
>
> commit d96b051d28b6042adcc8b8692a918abddf211aec
> Author: Dave Abrahams <dabrahams at apple.com>
> Date:   Tue Feb 23 15:12:24 2016 -0800
>
>     stdlib: initializePointee(_) => initialize(with:)
>
>
>     Tacking "Pointee" on just for unary operations (and especially
>     operations with an optional count) created inconsistency.
>
> So Swift 3 users have already migrated to this “better” name.
>
> I agree that initialize(to:) is consistent with the language we use for
> assigning values. But grammatically, I think initialize(with:) also makes
> perfect sense and is just as common.
>
>
> +1
>
>
> In general, if there’s controversy, I’ll stick with the existing
> conventions because there’s already enough to debate in this proposal.
>
> -Andy
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> 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/20160705/44870fe4/attachment.html>