<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 3, 2017, at 10:18 PM, Slava Pestov <<a href="mailto:spestov@apple.com" class="">spestov@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Oct 3, 2017, at 10:17 PM, Chris Lattner <<a href="mailto:clattner@nondot.org" class="">clattner@nondot.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; 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=""><br class="Apple-interchange-newline">On Oct 3, 2017, at 10:15 PM, Slava Pestov <<a href="mailto:spestov@apple.com" class="">spestov@apple.com</a>> wrote:<br class=""><br class=""><br class=""><br class=""><blockquote type="cite" class="">On Oct 3, 2017, at 10:14 PM, Chris Lattner <<a href="mailto:clattner@nondot.org" class="">clattner@nondot.org</a>> wrote:<br class=""><br class="">On Oct 2, 2017, at 11:11 PM, Slava Pestov <<a href="mailto:spestov@apple.com" class="">spestov@apple.com</a>> wrote:<br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">In any case, even if you’re opposed to these approaches, I’d love for the “alternatives considered” section to indicate what the objection is. I am really very concerned that you’re causing a keyword/attribute explosion and conceptual complexity by adding too many small things to individual parts of the language. We would ideally have a simple and holistic solution to resilience.<br class=""></blockquote><br class="">I agree with that keyword/attribute explosion is a concern. We also plan on submitting a proposal to add a @fixedContents attribute for structs (currently implemented as @_fixed_layout) which enables more efficient access patterns in resilient code, for example direct access of stored properties, at the cost of preventing new stored properties from being added in a binary-compatible manner. So we would have ‘nonexhaustive’ enums, @fixedContents structs, and @inlinable functions/properties/initializers.<br class=""></blockquote><br class="">Yes, and then we’ll need something else for classes as well (*head explodes*).<br class=""></blockquote><br class="">FWIW, I was hoping we wouldn’t need to expose any such attribute for classes (or protocols) at all, because classes are already “slow” and anything we do to make them resilient doesn’t make things much “slower”. But that could change, of course.<br class=""></blockquote><br style="font-family: Helvetica; font-size: 12px; 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: 12px; 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="">But everyone knows that NSObject is fixed size, right?</span><br style="font-family: Helvetica; font-size: 12px; 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=""></div></blockquote><div class=""><br class=""></div>Yeah, but the compiler could handle NSObject as a special case. Are there enough other special cases that it is worth documenting and exposing a fragile attribute on classes to the user?</div></div></div></blockquote><br class=""></div><div>My point is that NSObject isn’t a special case. It is simply a very commonly known case right now. While I agree that we can ignore this concern in the short term, in the long term evolution of Swift, the exact same concept will pop up at some point. It is a really really high value optimization for things that are at a low level of the stack.</div><div><br class=""></div><div>-Chris</div><div><br class=""></div><div><br class=""></div><br class=""></body></html>