<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jan 9, 2018, at 11:48 AM, Chris Lattner via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="Singleton"><blockquote type="cite" style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;" class="">IMO that isn’t a question we should be asking any more except in cases where an existing implementation is causing active harm. Which, confusing name aside, this type isn’t (aside from API sprawl I guess).<br class=""></blockquote><br style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">It directly impacts code size for applications of swift that use the standard library as a standard library, e.g. a raspberry pi dev situation.</span></div></div></blockquote><div><br class=""></div><div>I’m not arguing that we should have profligate bloat in the Standard library, but I feel that if we are seriously talking about scenarios where we want a super-svelt Standard library for particular use-cases where code size and other factors are a major concern, then I think that discussion goes well beyond just cutting out APIs like Mirrors. &nbsp;Depending on the domain, other parts of the Standard library seem like prime candidates to jettison as they may not carry their weight *in those contexts*, even if those APIs are well-used in others.</div><div><br class=""></div><div>In other words, we have various knobs we can pull here in this design space, and the needs of Swift in different domains may be slightly different to be worth exploring different options where appropriate. &nbsp;That’s not to say that the ideas you are putting forth don’t have merit, but I think there is a danger with lumping all of this up with the discussion about ABI stability in Swift 5. &nbsp;More generally, I do think the idea of possibly carving up the Standard Library into layers is a possible useful design idiom when considering Swift being used in different contexts with different requirements/needs/constraints, but an exploration of that idea doesn’t have to be tied to ABI stability.</div></div></body></html>