<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Oct 2, 2017 at 5:21 PM, Slava Pestov <span dir="ltr"><<a href="mailto:spestov@apple.com" target="_blank">spestov@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks for taking a look!<br>
<span class=""><br>
> On Oct 2, 2017, at 2:19 PM, Nevin Brackett-Rozinsky <<a href="mailto:nevin.brackettrozinsky@gmail.com">nevin.brackettrozinsky@gmail.<wbr>com</a>> wrote:</span><span class=""><br>
> 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>
<br>
</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></blockquote><div><br></div><div> Hmm, good question!</div><div><br></div><div>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><br></div><div>Nevin</div></div></div></div>