On Oct 2, 2017, at 10:58 PM, Chris Lattner via swift-evolution 
<[email protected]> 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.

-Joe
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to