> 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.
Slava
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
