[swift-evolution] [swift-evolution-announce] [Accepted, pending implementation] SE-0054: Abolish ImplicitlyUnwrappedOptional type

[Russ Bishop]

This seems like it would be a useful facility in general - the community may be able to provide audited headers even if the maintainers of the original project have zero interest in merging those changes. That burden is unreasonably high if it requires constant merging of the headers.

Russ

> On Mar 31, 2016, at 2:24 PM, Shawn Erickson via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
> 
> On Thu, Mar 31, 2016 at 9:43 AM Chris Lattner <clattner at apple.com <mailto:clattner at apple.com>> wrote:
> That said, this is the sort of proposal that can have a profound impact on the actual experience using unaudited APIs.  The core team believes that the experience will be good, but we would like to get some experience moving a couple of existing projects (both low-level code that interacts with C, and an “App” project working with high level frameworks) to see what the impact is in practice.  If something unexpected comes up, we will revisit this, and potentially reject it later.
> 
> On the topic of unaudited APIs. Does a recommended way exist that I as say a user of on an unaudited C API / library can add attributes to the C API for my use in Swift? (e.g. code that I don't own, I just use)
> 
> It is likely a number of C APIs won't get attributed for improved use in Swift by the authors so having a good way that the community could overlay attributes for the benefit of Swift could be helpful.
> 
> Anything better then cloning headers?
> 
> -Shawn
> _______________________________________________
> 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/20160331/11cc8b1b/attachment.html>