[swift-evolution] Renaming for Protocol Conformance

[Johannes Neubauer]

Von meinem iPhone gesendet
> Am 02.09.2016 um 17:56 schrieb Thorsten Seitz via swift-evolution <swift-evolution at swift.org>:
> 
>> Am 24.08.2016 um 21:35 schrieb Xiaodi Wu via swift-evolution <swift-evolution at swift.org>:
>> 
>>> On Wed, Aug 24, 2016 at 1:59 PM, Jonathan Hull <jhull at gbis.com> wrote:
>>> 
>>>> On Aug 24, 2016, at 7:48 AM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>>>> 
>>>>> On Wed, Aug 24, 2016 at 3:39 AM, Jonathan Hull <jhull at gbis.com> wrote:
>>>>> 
>>>>>> On Aug 23, 2016, at 8:35 AM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>>>>>> 
>>>>>>> On Tue, Aug 23, 2016 at 3:02 AM, Jonathan Hull <jhull at gbis.com> wrote:
>>>>>>> 
>>>>>>>> On Aug 22, 2016, at 11:32 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>>>>>>>> 
>>>>>>>>> On Mon, Aug 22, 2016 at 11:59 PM, Jonathan Hull via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>>> 
>>>> Protocols are not merely a vehicle for delivering a reusable bag of code. One of its most essential purposes is to constrain the shape or API of its conforming types. Therefore, it is a feature, not a bug, that with every choice of name in a protocol you foreclose the possibility of composing that protocol with others that might have colliding names.
>>>> 
>>>> Currently, if you the protocol vendor have made the decision that `image` "makes the most sense in the protocol's context", you must have considered whether it would be absurd for a conforming type to have another use for `image`.
> 
> I find it a little bit strange to require from a protocol designer to foresee all future uses of a protocol. IMO protocols are not bags of code but encapsulate a certain (typically fine grained) semantic. How this semantic will be coupled with other semantics (i.e. protocols) is widely open.

I agree. Why should a language that supports:

1. type aliases and retroactive modeling (even adding protocol conformance to existing types to the extent that basic types implement user library protocols) and
2. discuss to add type aliases for generic types and existentials as well as 
3. something like *new type* for type aliases with nominal typing...

not allow to rename methods? The argument that protocols have to be designed by the "protocol vendor" foreseeing all its usages does not hold for every case. A language with type aliases and retroactive modeling allows for domain specificity via context dependent changes to a and renaming of a type. This can be used for internal DSLs (domain specific languages) and the like. 

I know that my point here is orthogonal to the original problem of renaming because of name clashes between protocols, but I address the more general question whether renaming of associated types, methods and the like wouldn't be a good (and consequent) thing.

All the best
Johannes

Von meinem iPhone gesendet
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160902/cd1664ed/attachment.html>