<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Oct 2, 2017, at 7:52 PM, Kelvin Ma <<a href="mailto:kelvin13ma@gmail.com" class="">kelvin13ma@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">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.<br class=""></div></div></blockquote><div><br class=""></div>Private members too. Consider this example,</div><div><br class=""></div><div>struct S {<br class=""> private func f() {}<br class="">}</div><div><br class=""></div><div>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.</div><div><br class=""></div><div>Slava</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Mon, Oct 2, 2017 at 9:43 PM, Slava Pestov <span dir="ltr" class=""><<a href="mailto:spestov@apple.com" target="_blank" class="">spestov@apple.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="">It would be a trivial change to allow @_versioned on private and fileprivate declarations, but there are two pitfalls to keep in mind:<div class=""><br class=""></div><div class="">- 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.</div><div class=""><br class=""></div><div class="">- 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.</div><div class=""><br class=""></div><div class="">For these reasons we decided against “private versioned” as a concept. I feel like internal is enough here.</div><span class="HOEnZb"><font color="#888888" class=""><div class=""><br class=""></div><div class="">Slava</div></font></span><div class=""><div class="h5"><div class=""> <br class=""><div class=""><blockquote type="cite" class=""><div class="">On Oct 2, 2017, at 4:54 PM, Taylor Swift <<a href="mailto:kelvin13ma@gmail.com" target="_blank" class="">kelvin13ma@gmail.com</a>> wrote:</div><br class="m_-1169024350654051407Apple-interchange-newline"><div class=""><div dir="ltr" class="">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.<br class=""></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Mon, Oct 2, 2017 at 6:42 PM, Xiaodi Wu <span dir="ltr" class=""><<a href="mailto:xiaodi.wu@gmail.com" target="_blank" class="">xiaodi.wu@gmail.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""><br class=""><div class="gmail_quote"><span class=""><div dir="auto" class="">On Mon, Oct 2, 2017 at 17:41 Taylor Swift <<a href="mailto:kelvin13ma@gmail.com" target="_blank" class="">kelvin13ma@gmail.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">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.</div></blockquote><div dir="auto" class=""><br class=""></div></span><div dir="auto" class="">Right, that’s @_versioned, essentially.</div><span class=""><div dir="auto" class=""><br class=""></div><div dir="auto" class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra"><div class="gmail_quote">On Mon, Oct 2, 2017 at 4:45 PM, Xiaodi Wu via swift-evolution <span class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br class=""><div class="gmail_quote"><div class=""><div class="m_-1169024350654051407m_-7952634603822794887m_7285399758680272494h5"><div class="">On Mon, Oct 2, 2017 at 16:37 Nevin Brackett-Rozinsky via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class=""></div></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""><div class="m_-1169024350654051407m_-7952634603822794887m_7285399758680272494h5"><div class=""><div class="gmail_extra"><div class="gmail_quote">On Mon, Oct 2, 2017 at 5:21 PM, Slava Pestov <span class=""><<a href="mailto:spestov@apple.com" target="_blank" class="">spestov@apple.com</a>></span> wrote:<br class=""></div></div></div><div class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks for taking a look!<br class="">
<span class=""><br class="">
> On Oct 2, 2017, at 2:19 PM, Nevin Brackett-Rozinsky <<a href="mailto:nevin.brackettrozinsky@gmail.com" target="_blank" class="">nevin.brackettrozinsky@gmail.<wbr class="">com</a>> wrote:</span><span class=""><br class="">
> 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.<br class="">
<br class="">
</span>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?<br class=""></blockquote></div></div></div><div class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote><div class=""><br class=""></div><div class=""> Hmm, good question!</div><div class=""><br class=""></div><div class="">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.</div></div></div></div><div class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div><div class="">Nevin</div></div></div></div></div></div><span class="">
______________________________<wbr class="">_________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailma<wbr class="">n/listinfo/swift-evolution</a><br class="">
</span></blockquote></div>
<br class="">______________________________<wbr class="">_________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailma<wbr class="">n/listinfo/swift-evolution</a><br class="">
<br class=""></blockquote></div><br class=""></div>
</blockquote></span></div></div>
</blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></div></div></div></div></blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></body></html>