<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:04 AM, Joe Groff <<a href="mailto:jgroff@apple.com" class="">jgroff@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="">On Oct 2, 2017, at 10:58 PM, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><div class=""><blockquote type="cite" class=""><br class="Apple-interchange-newline"><div class=""><div 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="">The major question I have is “why yet another attribute”. The thread about exhaustive/extensible enums is similarly proposing introducing another one-off way to be enums fragile, and this is directly related just for function-like things.</div><div 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=""><br class=""></div><div 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="">I’d love to see rationale in the proposal for why you’re not taking this in one of these directions:</div><div 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=""><br class=""></div><div 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="">1) Why not another level of access control? There is a reasonable argument that what you’re doing is making something “more public than public” or that you’re making the “body also public”. I’m not strongly in favor of this design approach, but if you agree, the doc should explain why you’re not in favor of it.</div><div 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=""><br class=""></div><div 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="">2) Why can’t we have a single Swift-wide concept that unifies all of the resilience ideas under a single umbrella like “fragile” - which indicates that the body of a declaration is knowable to clients? There is a very reasonable holistic design where “fragile public func” makes its body inlinable, and “fragile enum” similarly makes the cases knowable to the client (thus making exhaustive switching a possibility). I am strongly in favor of this approach.</div></div></blockquote><br class=""></div><div class="">I'm of two minds on this. So far, it has seemingly been the case that, for every kind of declaration, there's been exactly one resilience-related attribute, and with blurry enough vision you could say they're all really doing the same thing, "expose this declaration body directly to clients", which only makes sense as a concept for public API. If these properties hold, then sure, it might make sense to consider these all as one "extra-public" concept. On the other hand, we don't know yet whether these properties will hold in the long term as we're actively designing the facilities we need for ABI stability and resilience. From an incremental, iterative design perspective, I think it's wiser to keep them all separate attributes, even if it's a bit messy in the short term. Once the design stabilizes, we can look at whether it makes sense to fold related concepts together. It's easier to fold different things together after the fact then to try to separate things after they've been mixed together.</div></div></div></blockquote><br class=""></div><div>As I said above, I pretty strongly disagree with this approach. It encourages a “one attribute/declmodifier/keyword per decl kind” approach, which is user hostile. It doesn’t make sense for “exhaustive" to apply to enums, "@inlinable” to apply to function-like things, something else to apply to structs, something else to apply to classes, etc.</div><div><br class=""></div><div>I’d rather that we define one “thing” which can be parameterized. I’d propose that that be named “fragile” because it appropriately carries negative connotations. If some declaration has multiple levels of fragility that we want to support, we can allow it to be parameterized, e.g.:</div><div><br class=""></div><div>/// C style fragility, all things about the decl are fragile.</div><div>fragile struct Foo { … }</div><div class=""><br class=""></div>/// Just layout is fragile, but not other things (whatever they would be?)<br class=""><div class="">fragile(layout) struct Foo { … }</div><div class=""><br class=""></div><div class="">I pretty strongly believe that we should start with the default of having a unifying principle that ties together all resilience concerns under a single umbrella, and fission those concerns when we’re faced with something that forces it. Starting with them split and hoping that we’ll come around to merging them someday is the wrong side of optimism IMO.</div><div class=""><br class=""></div><div class="">We’ve been talking about this approach for years, which is why I’m somewhat surprised to see the new direction these things are taking.</div><div class=""><br class=""></div><div class="">-Chris</div></body></html>