[swift-evolution] [RFC] "Library Evolution Support in Swift ('Resilience')"

[David Smith]

> On Feb 11, 2016, at 5:57 PM, Drew Crawford via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On Feb 11, 2016, at 7:32 PM, Jordan Rose <jordan_rose at apple.com <mailto:jordan_rose at apple.com>> wrote:
>> 
>> Knowing for sure that your client is inlining isn't extra information over knowing it may inline.
>> 
>> (Technically, a C function marked 'inline' and not 'static' isn't guaranteed to be inlined either, but in practice nobody does that because the rules are awful.)
> 
> I'm referring specifically to the C/C++ case, where "inlining a dynamic library" means "calling a function (or macro) with a body that appears in a .h file".
> 
> In that case I am 100% sure that the function was inlined.  I look at the header file and there it is.
> 
> An argument was advanced that "we do this already in C/C++" We do *something*, but not *this*.
> 
>> I really don't think we want average app developers to be accessing types like NSRect indirectly, though, and if you have to opt in to accessing NSRect directly, well, everyone will do it all the time, and it'll cease to be meaningful.
> 
> It seems to me that this can be solved at the xcodeproj level.  Xcode projects have "default settings" and somebody can ship in that template "--inline=UIKit".
> 
> The argument that "we want average app developers to be accessing types like NSRect indirectly" sounds vendor-specific to me, there is a good way here to ship that intuition in a vendor-specific location.
> 
> 

A less vendor-specific example would be the Int struct in the standard library.

	David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160211/73f9d63d/attachment.html>