> On Oct 3, 2017, at 10:03 PM, Chris Lattner <[email protected]> wrote:
>
>
>> On Oct 3, 2017, at 10:04 AM, Joe Groff <[email protected]> wrote:
>>
>>> 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.
>
> 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.
-Joe
>
> 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.:
>
> /// C style fragility, all things about the decl are fragile.
> fragile struct Foo { … }
>
> /// Just layout is fragile, but not other things (whatever they would be?)
> fragile(layout) struct Foo { … }
>
> 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.
>
> 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.
>
> -Chris
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
