<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=""><div><blockquote type="cite" class=""><div class="">On Aug 2, 2017, at 2:20 PM, Víctor Pimentel Rodríguez <<a href="mailto:vpimentel@tuenti.com" class="">vpimentel@tuenti.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">On Wed, Aug 2, 2017 at 1:09 PM, Gor Gyolchanyan via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<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=""><div class=""><span class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap:break-word" class=""><div class=""><div class=""><div class=""> and if you have a huge entity, it doesn't get better just because you split it and hide its complexity.</div></div></div></div></div></blockquote><div class=""><br class=""></div></span><div class="">Splitting and hiding complexity is by far the only reasonable way of dealing with huge entities. If the entity gains too much responsibility, it's probably a good idea to split it into several smaller entities. If the entity contains a large amount of accidental complexity that solely serves the purpose of enabling a select set of intended features, then it's probably a good idea to hide the accidental complexity away from users of the entity.</div><div class=""><br class=""></div><div class="">In fact, that's exactly why I always wished that protocols could get private requirements that are there solely for use in protocol extensions and are otherwise hidden from existence. I haven't talked about this in detail because I don't see a reasonable way of implementing it yet.</div></div></div></blockquote><div class=""><br class=""></div><div class="">+1, although most times I wanted this because of the impossibility of defining stored attributes in protocol extensions, let alone private stored attributes.</div></div></div></div></div></blockquote><div><br class=""></div><div>Considering how private access level works within file scope because of code visibility guarantees (the compiler is guaranteed to be able to see both the type and the extension at the same time), the same could be said about stored properties in extension within file scope. Since bot the type and the extension are defined in the same file, there's no way for the type to get improperly laid out, since all stored properties are still visible at the same time. I wonder what it would take to implement this...</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra">-- </div><div class="gmail_extra">Víctor Pimentel<div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" style="font-size:12.8px" class=""><div style="font-size:12.8px" class=""></div></div></div></div></div></div></div></div></div></div></div></div>
</div></div>
</div></blockquote></div><br class=""></body></html>