> On Oct 2, 2017, at 7:52 PM, Kelvin Ma <kelvin1...@gmail.com> wrote:
>
> 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.
Private members too. Consider this example,
struct S {
private func f() {}
}
The member S.f mangles as
_T06struct1SV1f33_AB643CAAAE0894CD0BC8584D7CA3AD23LLyyF. In this case, I
suppose we won’t need the private discriminator because there can only be one
S.f that’s directly a member of S, and not an extension. However imagine if two
different source files both defined extensions of S, with a private member f.
You would need to disambiguate them somehow.
Slava
>
> On Mon, Oct 2, 2017 at 9:43 PM, Slava Pestov <spes...@apple.com
> <mailto: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
>> <mailto: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
