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 > <[email protected]> wrote: > > > > On Thu, Mar 31, 2016 at 9:43 AM Chris Lattner <[email protected] > <mailto:[email protected]>> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
