On 20.09.2016 17:48, Martin Waitz wrote:
Hello everybody,

Several suggestions are floating around about explicitly marking a method
to implement a protocol requirement.


class Foo : Bar {
    implement func foo() {...}

However, with extensions we can already do something very similar:

Yes, I also mentioned it in one of the message. Personally I don't like this solution but I do remember that someone from core team mentioned it.

It allows you to have 'safe' code and 'unsafe' - i.e. where you can be lazy and don't provide more info for compiler and got later the problem with protocol conformance we are discussing here; and you can have 'safe' code in extension - where compiler will help you.

Then, shouldn't we disallow protocol conformance 'in-place' in type's definition? So, if you need to conform to protocol - only extension is the syntax for this. In this case I can understand the idea. Otherwise - can't.

So, if I want safe code this suggestion forces me to break my type's definition to a number of extension blocks. Right now there is a lot of code was written using 'in-place' conformance and not related to protocol methods in extensions. I believe there will be a lot of work to apply for new rules.

And if I have public methods/props *logically* related to implemented methods of protocol - I'll have to keep them in 'main' definition or in another extension.

Also what about marking default implementation methods in *protocol* extension as was mentioned by Charles Srstka? I.e. in "extension P {...}"

  class Foo {
  extension Foo: Bar {
      func foo() {...}

Maybe simply adding a new warning would already help.
Extensions which introduce new protocol conformances could be reserved for
those methods which are already defined within the protocol. Whenever such
an extension contains an unrecognized method, we could issue a warning.
Or maybe even an error, but we should allow private methods as an exception
(for helper functions which are clearly not related to the protocol).

This way, when the programmer wants to make sure that her new method is
used by a protocol then she can simply put that method in an extension.

I wonder if *any* developer don't want to be sure the method she defined exactly to implement protocol's requirement will be "used by a protocol".

Something like "I implemented this particular protocol's requirement in my type... but.. you know, if something is changed in that protocol and because of this the method will not play a role of implementation... not a big problem, this is not very important code at all". :-)
swift-evolution mailing list

Reply via email to