[swift-evolution] Unmanaged, and COpaquePointer vs. Unsafe(Mutable)Pointer
Jacob Bandes-Storch
jtbandes at gmail.com
Fri Dec 11 01:16:58 CST 2015
We could add @availability(*, deprecated=...) to the existing declarations
but keep them around until Swift 3. I'm not sure whether this is preferable
to simply waiting until Swift 3.
I'm also not sure how the migration stuff usually works, whether it'd be
worth adding a migration step for this or just letting users see & fix the
deprecation warnings themselves.
Earlier in this thread, Jordan said
Swift does support overloading on return type, but the downside is you need
> to always provide context, which makes it harder to break things up into
> multiple statements. So we generally avoid it unless there's a compelling
> reason.
>
Either way, I'd be happy to prepare a patch for this, but I'm guessing I
should wait until the proposal is accepted to do so.
Jacob
On Thu, Dec 10, 2015 at 11:07 PM, Chris Lattner <clattner at apple.com> wrote:
> This LGTM as far as being a well thought out proposal, and I’d certainly
> like to see COpaquePointer go away. :-)
>
> One thing to consider incorporating into your proposal, we’re trying to
> keep Swift 2.2 source compatible with Swift 2 (thought providing migration
> warnings where it makes sense). Should your proposal wait for swift 3, or
> is there some piece that would be good to go into swift 2.2 to aid
> migration?
>
> -Chris
>
>
>
>
> On Dec 10, 2015, at 10:58 PM, Jacob Bandes-Storch <jtbandes at gmail.com>
> wrote:
>
> I haven't seen much feedback here. Are there any objections?
>
> What's needed for a proposal to go from pull-request to "Awaiting Review"?
>
> Jacob
>
> On Tue, Dec 8, 2015 at 9:52 PM, Chris Lattner <clattner at apple.com> wrote:
>
>> On Dec 8, 2015, at 8:07 PM, Jacob Bandes-Storch via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>> Proposed: https://github.com/apple/swift-evolution/pull/44
>>
>>
>> A related topic that would be great to discuss for Swift 3: right now
>> nullable C pointers import directly as UnsafePointer, and UnsafePointer are
>> therefore nullable. While it is true that they are unsafe :-), it would be
>> more true to the Swift model to import them as optional unsafe pointers.
>>
>> There are tradeoffs on both sides, just something to consider.
>>
>> -Chris
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151210/c392c1c3/attachment.html>
More information about the swift-evolution
mailing list