[swift-evolution] Mark protocol methods with their protocol

[Vladimir.S]

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.
>
> E.g.:
>
>> 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".  :-)