> On Dec 22, 2017, at 1:50 AM, Johannes Weiß <johanneswe...@apple.com> wrote:
> totally agree that these attributes are necessary, they should be in Swift as 
> soon as we bike shedded the right name. But to prevent them from being placed 
> everywhere without thinking I propose to introduce a compiler mode at the 
> same time.
> Performance testing is hard and takes time. So I'm pretty sure that as soon 
> as one @abiPublic/@inlinable has proven to improve performance, library 
> authors will just start putting them anywhere as there's no downside besides 
> making the code harder to read.
> What is the downside of bringing the attributes and the compiler mode at the 
> same time. Am I massively underestimating the amount of work required for 
> such mode?

ABI stability for the standard library is our top priority for Swift 5. While 
adding a ‘completely fragile’ compiler mode should be straightforward in 
theory, the devil is in the details, and I don’t think we can commit to 
delivering this feature any time soon.

> Cool. Just to be sure I understand you correctly: Assuming your proposal gets 
> implemented as proposed, a function that does _not_ have the @inlinable 
> attribute it won't be specialised across modules, ever. Correct?

That is correct. This is already the behavior today, so there’s no change here.

swift-evolution mailing list

Reply via email to