| Suggestion 1 | Suggestion 2 | Suggestion 3 | Swift 3 | Implication of #3 |
|---|---|---|---|---|
| public | open | open public | open | open |
| closed public | public | public | public | public |
| fixed public | ||||
| final public | closed | final public | final public | final public |
| internal | internal | internal | internal | internal |
| final internal | final internal | final internal | final internal | final internal |
| private | private | private | fileprivate | private |
| final private | final private | final private | final fileprivate | final private |
| scoped | scoped | scoped | private | scoped |
openis no more an exclusive access modifier, which shouldn't exist in the first place, because of the mentioned exclusivity. That's what attributes are meant for.- Allowing
closed public protocols seems straightforward for Suggestion 1. - First suggestion aligns the
closedattribute very well withfinaland its purpose becomes crystal clear. scopedis a straw_hat_name from the on going discussions, you can replace it with something better.fixed publicis from Matthew's discussion thread.- Third suggestion makes
openas an attribute, however this is a breaking change for all other types different form classes, because currently protocols have open semantics, and value types might get subtypes one day, which makes them closed by today's standards. The default in the first suggestion is alway open, compared to the third suggestion, which is closed. - The implication of the third suggestion is the necessary fix for protocols:
open/public protocol(shown in the last row).