Is this only a problem with fileprivate or does it extend to private members too? I feel like this would be a very valuable feature to support.
On Mon, Oct 2, 2017 at 9:43 PM, Slava Pestov <spes...@apple.com> wrote: > 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> wrote: > >> >> On Mon, Oct 2, 2017 at 17:41 Taylor Swift <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> 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> wrote: >>>> >>>>> On Mon, Oct 2, 2017 at 5:21 PM, Slava Pestov <spes...@apple.com> >>>>> wrote: >>>>> >>>>>> Thanks for taking a look! >>>>>> >>>>>> > On Oct 2, 2017, at 2:19 PM, Nevin Brackett-Rozinsky < >>>>>> 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 >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> swift-evolution@swift.org >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> >>>> >>> > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
