> On Oct 4, 2017, at 9:46 AM, Joe Groff via swift-evolution > <swift-evolution@swift.org> wrote: > > > > On Oct 3, 2017, at 10:03 PM, Chris Lattner <clatt...@nondot.org> wrote: > >> >>> On Oct 3, 2017, at 10:04 AM, Joe Groff <jgr...@apple.com> wrote: >>> >>> On Oct 2, 2017, at 10:58 PM, Chris Lattner via swift-evolution >>> <swift-evolution@swift.org> wrote: >>>> >>>> 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. >>>> >>>> I’d love to see rationale in the proposal for why you’re not taking this >>>> in one of these directions: >>>> >>>> 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. >>>> >>>> 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. >>> >>> 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. >> >> 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. > > Premature abstraction is user-hostile too. These things all have subtly > different impacts on language semantics, some of which we're still > discovering as we develop their designs.
These are also ultimately all "power user" features that only a handful of first and second parties shipping binary frameworks need to think about. Apps don't need to care about this at all, and most packages outside the OS can be shipped as source or as fragile binaries, for which these sorts of attributes are unnecessary for the build system to (eventually) provide the desired performance. -Joe _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
