> On Apr 25, 2016, at 8:39 PM, Russ Bishop via swift-evolution
> <[email protected]> wrote:
>
> There aren’t enough +1s in the world for this, I fully endorse your proposal
> and would like to subscribe to your newsletter ;)
>
> Do you envision the apinotes will be the vehicle for performing the bridging
> since ObjectiveCBridgeable was deferred? I actually haven’t checked if that
> was merged but left as a private protocol or if it still only works in
> collections.
_ObjectiveCBridgeable is still there, and despite the underscore and the fact
that it doesn’t match the interface in the deferred proposal, it’s essentially
fully implemented. The Clang side (swift_bridge attribute) is in swift-clang,
and there is API notes support for adding it without modifying headers.
- Doug
>
> Russ
>
>
>> On Apr 22, 2016, at 10:18 AM, Tony Parker via swift-evolution
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>> Dear swift-evolution denizens,
>>
>> As you know from our announcement of Swift Open Source and our work on
>> naming guidelines, one of our goals for Swift 3 is to “drop NS” for
>> Foundation. We want to to make the cross-platform Foundation API that is
>> available as part of swift-corelibs feel like it is not tied to just Darwin
>> targets. We also want to reinforce the idea that new Foundation API must fit
>> in with the language, standard library, and the rapidly evolving design
>> patterns we see in the community.
>>
>> You challenged us on one part of this plan: some Foundation API just doesn’t
>> “feel Swifty”, and a large part of the reason why is that it often does not
>> have the same value type behavior as other Swift types. We took this
>> feedback seriously, and I would like to share with you the start of an
>> important journey for some of the most commonly used APIs on all of our
>> platforms: adopting value semantics for key Foundation types.
>>
>> We have been working on this for some time now, and the set of diffs that
>> result from this change is large. At this point, I am going to focus effort
>> on an overview of the high level goals and not the individual API of each
>> new type. In order to focus on delivering something up to our quality
>> standards, we are intentionally leaving some class types as-is until a
>> future proposal. If you don’t see your favorite class on the list — don’t
>> despair. We are going to iterate on this over time. I see this as the start
>> of the process.
>>
>> One process note: we are still trying to figure out the best way to
>> integrate changes to API that ship as part of the operating system (which
>> includes Foundation) into the swift-evolution review process.
>> Swift-evolution is normally focused on changes to functionality in the
>> compiler or standard library. In general, I don’t expect all new Foundation
>> API introduced in the Darwin/Objective-C framework to go through the open
>> source process. However, as we’ve brought up this topic here before, I felt
>> it was important to bring this particular change to the swift-evolution list.
>>
>> As always I welcome your feedback.
>>
>> https://github.com/apple/swift-evolution/blob/master/proposals/0069-swift-mutability-for-foundation.md
>>
>> <https://github.com/apple/swift-evolution/blob/master/proposals/0069-swift-mutability-for-foundation.md>
>>
>> Thanks,
>> - Tony
>>
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> [email protected] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
