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