[swift-evolution] Proposal: Intermediate mutation qualifier for protocol functions on reference-types

[Gwendal Roué]

> Le 11 déc. 2015 à 20:44, Slava Pestov <spestov at apple.com> a écrit :
> 
> 
>> On Dec 11, 2015, at 11:43 AM, Gwendal Roué <gwendal.roue at gmail.com <mailto:gwendal.roue at gmail.com>> wrote:
>> 
>> 
>>> Le 11 déc. 2015 à 20:34, Slava Pestov via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> a écrit :
>>> 
>>> For this reason I’m in favor of going in the opposite direction, and prohibiting classes from conforming to protocols with mutating requirements.
>> 
>> This would go too far.
>> 
>> It’s common to write a protocol with mutating methods just because the protocol designer expects that some adopting structs may want to mutate in their implementation. And in this case the goal of the protocol designer is certainly not to limit the protocol adoption to structs.
>> 
>> Here is an example:
>> 
>> 	protocol DatabaseFetchable {
>> 	  mutating func awakeFromFetch()
>> 	}
>> 	extension DatabaseFetchable {
>> 	  func fetch() -> Self {
>> 	    var value = /* details omitted */
>> 	    value.awakeFromFetch()
>> 	    return value
>> 	  }
>> 	}
>> 
>> The protocol does not care at all if awakeFromFetch mutates or not. But the protocol designer does: if the awakeFromFetch method were not declared mutating, many structs could simply not adopt it.
>> 
>> Gwendal Roué
>> 
> 
> I guess the question is, does it even make sense to write a protocol that can be adopted by both a struct and a class, if the protocol has mutating members?

I just gave you an answer above: when the protocol designer does not care whether the protocol should be adopted by a struct or a class. Who knows? Maybe the user will adopt the protocol in an extension of an existing type, which happens to already be a struct or a class? Maybe the user will want to adopt the protocol in the base class of a class hierarchy? Who knows?

Gwendal Roué
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151211/511e47ae/attachment.html>