Thanks for taking a look! > On Oct 2, 2017, at 2:19 PM, Nevin Brackett-Rozinsky > <nevin.brackettrozin...@gmail.com> wrote: > > I am hugely in favor of an @inlinable attribute, and I look forward to its > arrival with relish! > > Some feedback: > > 1. I think “inlinable” is the right spelling: it indicates that something is > *able* to be inlined.
Yeah, it seems this is the spelling we’re going to go with. > > 2. If I want to pass an @inlinable function as an argument (say, to map or > filter) can I do so directly or must I use a closure which calls the > inlinable function? You can pass it directly. From the viewpoint of code that uses an inlinable function, it behaves exactly the same as one that does not have the attribute. > 3. Even though @inlinable will have no effect on declarations which are not > public, we should still allow it to be placed there. That way when the access > level is later changed to be public, the attribute is already where it should > be. This is similar to why we permit, eg., members of an internal type to be > declared public, which was discussed and decided previously on Swift > Evolution. This is an interesting point. Do you think the attribute should be completely ignored, or should the restrictions on references to non-public things, etc still be enforced? Slava > > Other than that the proposal looks great, thanks for writing it up. > > Nevin _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
