Introducing role keywords to reduce hard-to-find bugs

Evolution Pitches
67

Hello @Erica_Sadun, could you provide a statement why the newer version of the proposal has such a dramatic shift of design?

I had a quick reading over the discussion until the very recent responses (which I have not read yet), and I had the impression that the support of the idea was towards a single new mandatory keyword design using default for default implementations (originally pitched by @hartbit).

I also think it is very important that we, the Swift community, find an agreement on the design first, before we're asking someone to implement it. It would be really fatal to let someone implement such a huge change with lot's of different keywords and rules, then throw everything away and re-implement it again because the design wasn't good enough.

I personally do not like this shift of the design. What I really would wish is Swift to adopt a mandatory default keyword and that's about it. default perfectly describes that the current extension supposed to be a default implementation. If it's mandatory then you get compile time guarantees that the implementation was satisfied. By this date I don't know if default implementations with default parameters are real default implementations. It just works so I'm happy with that fact, but I don't have strong guarantees I can rely on. From the readers perspective we also get informations about the dispatch behaviour of the extension just by checking if the keyword is absent or not.

  • required does not make any sense to me because there is nothing required in a sense of a default implementation, a protocol is not required to have any default implementations at all.
  • extended does not add anything new to the language (this has been mentioned in the very beginning of this thread) and can stay implicit.
  • I'm not sure I recall it correctly, but I have a feeling that override does not work because of retroactive conformances?! Can someone please clarify this.
  • final is completely orthogonal to this proposal because it adds a new functionality instead being a nice code guard like default would be. In fact, I pitched this idea 2,5 years ago but never pursued it really:
2 Likes