It would be a trivial change to allow @_versioned on private and fileprivate declarations, but there are two pitfalls to keep in mind:
- Private symbols are mangled with a ‘discriminator’ which is basically a hash of the file name. So now it would be part of the ABI, which seems fragile — you can’t move the private function to another source file, or rename the source file. - Similarly, right now a @_versioned function becoming public is an ABI compatible change. This would no longer work if you could have private @_versioned functions, because the symbol name would change if it became public. For these reasons we decided against “private versioned” as a concept. I feel like internal is enough here. Slava > On Oct 2, 2017, at 4:54 PM, Taylor Swift <kelvin1...@gmail.com> wrote: > > Right now @_versioned is only for internal declarations. We should have > something similar for private and fileprivate declarations. I think most > people use those modifiers for code organization, not binary resilience, so > we would do well to make the two intents separate and explicit. > > On Mon, Oct 2, 2017 at 6:42 PM, Xiaodi Wu <xiaodi...@gmail.com > <mailto:xiaodi...@gmail.com>> wrote: > > On Mon, Oct 2, 2017 at 17:41 Taylor Swift <kelvin1...@gmail.com > <mailto:kelvin1...@gmail.com>> wrote: > I think we should try to separate visibility from access control. In other > words, the compiler should be able to see more than the user. I want to be > able to write private and internal code that cannot be called explicitly in > source, but can still be inlined by the compiler. Right now people are doing > this with underscored methods and variable names but I don’t think that’s a > good convention to use. We should have something at the language level that > enforces that something shouldn’t be referenced by name outside of its scope, > but is public for all compilation and ABI purposes. Maybe an attribute like > @visible or a new keyword or something. > > Right, that’s @_versioned, essentially. > > > On Mon, Oct 2, 2017 at 4:45 PM, Xiaodi Wu via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > This is unduly restrictive; @_versioned (despite being the wrong spelling) is > what we want here. To be callable from an inlinable function, internal things > need only be visible in terms of public ABI, not necessarily inlinable, just > as public things need only be public and not necessarily inlinable. > On Mon, Oct 2, 2017 at 16:37 Nevin Brackett-Rozinsky via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > On Mon, Oct 2, 2017 at 5:21 PM, Slava Pestov <spes...@apple.com > <mailto:spes...@apple.com>> wrote: > Thanks for taking a look! > > > On Oct 2, 2017, at 2:19 PM, Nevin Brackett-Rozinsky > > <nevin.brackettrozin...@gmail.com > > <mailto:nevin.brackettrozin...@gmail.com>> wrote: > > 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? > > Hmm, good question! > > I rather like the idea Greg Parker put forth, where non-public @inlinable > items can be used by public @inlinable ones, which implies that the > restrictions should indeed still apply—something @inlinable can only > reference public or @inlinable things. > > Nevin > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org <mailto:swift-evolution@swift.org> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org <mailto:swift-evolution@swift.org> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> > > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
