As an alternative to having `open` as a separate access level, we could instead have it merely imply `public`: the canonical form would be `public open`, but source code could just say `open`. Generated interfaces would always say `public open`, so searching for `public` in those would work as you want it to. I would not support this. Open and public are orthogonal concepts, just like final and public are today.
Just because your internal implementation details involve classes and subclasses, you shouldn't have to expose that to the whole world. I think it should be an attribute/qualifier on the access level (similar to mutability for properties). You may wish to allow internal subclassing while preventing external subclassing (e.g. The API isn't stable yet, you're thinking of opening it publicly later but you want to refine it through internal usage first). Or, as I mentioned before, perhaps you are forced to return an "abstract" class because we don't have sealed protocols. These are all decisions for the API author, and by having the openness scopes to access level we give them ultimate flexibility to annotate which parts of their API can be replaced and by whom. Karl > > > > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
