> On Feb 13, 2017, at 7:45 AM, Matthew Johnson <[email protected]> wrote:
>
> If you look closely, when most people say “closed enum” they mean a fixed,
> complete set of cases that are all public. But when people say “closed
> protocol” they don’t actually mean a fixed, complete set of conformances that
> are all public. They simply mean clients cannot add conformances. This is
> the semantic contract of resilient enums, not closed enums.
Yes, our traditional terminology here has been a little bit confused.
>> What I instead suggest is that we think of a closed enum as being like a
>> fragile (non-resilient) struct. In both cases, you are committing to a
>> particular design for the type. So I think we should give them both the same
>> keyword—something like:
>>
>> @fixed struct Person {
>> var name: String
>> var birthDate: Date
>> }
>> @fixed enum Edge {
>> case start
>> case end
>> }
>>
>
> You omitted public here. Does that mean you intend for `@fixed` to imply
> public visibility? If so, I could get behind this. But I am curious why you
> made it an attribute rather than a keyword.
No, I'm sorry, I meant to say `@fixed public struct` and `@fixed public enum`.
I don't think `@fixed` implies public-ness, either, so it would need to be
paired with a `public` keyword. There *may* be keywords we could use that
would, like `exposed`, but I'm not sure we want to make this feature so
prominent, and I'm not sure how that would work with classes you want to both
expose and permit subclassing of. (Would that be `exposed open class Foo`?)
>> I don't see it mentioned here (maybe I just missed it), but even though we
>> *could* do exhaustiveness checking on non-open protocols, I'm not convinced
>> that's a good idea. Usually when you have several types conforming to a
>> protocol, you should access type-specific behavior through polymorphism, not
>> by switching on the protocol. A protocol is supposed to represent a
>> behavior, not just mark a type in some arbitrary way.
>
> I agree that you should usually be adding polymorphism, but preventing
> exhaustive switch on what is effectively a style argument seems like an
> unnecessary restriction to me. There will be times when it could be used to
> good effect. I think the community has done a pretty good job of figuring
> out how to use Swift’s many features well and don’t believe it would be
> frequently abused.
I agree we shouldn't change the language to *prevent* bad style. But this would
go beyond that—we'd be putting specific engineering effort solely into
*enabling* bad style. At minimum, this should fall so far down our to-do list
that we'll probably never get to it.
>> I still support this general approach. One spelling could simply be
>> `@nonopen`. Although if we don't use `closed`, we could simply use `@closed`
>> like I suggested—here it really *would* be an antonym to `open`.
>
> I like the idea of using `@nonopen` for the transitional attribute. Both
> because it “removes the openness” that `public protocol` currently implies.
> In that sense it is probably the most accurate term we could find and it’s
> also pretty concise.
It also sounds a little bit awkward, which is normally a reason not to use it,
but perhaps that's actually a good thing in a temporary, transitional keyword.
>>> A similar mult-release strategy would work for migrating public enums.
>>
>> What is it that needs migrating here? Lack of exhaustiveness checking? It
>> sounds like we were planning to break that anyway in some fashion.
>
> Public enums are not currently resilient. Clients are allowed to switch over
> them without a `default` clause. This means that client code will fail to
> compile in a version of Swift where `public enum` has the resilient contract
> unless the library changes to adopt closed semantics or the client adds a
> default case.
My thinking was that, since most existing `public` enums should probably not be
`@fixed`, we should just change the behavior and let some switch statements
break. Most `public` protocols, on the other hand, ought to become `open`, so
we should flag that change and require an explicit marker like `@nonopen` if
you really don't want to change over. But I could be convinced otherwise.
--
Brent Royal-Gordon
Architechies
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
