[swift-evolution] Proposal: Intermediate mutation qualifier for protocol functions on reference-types
Chris Lattner
clattner at apple.com
Fri Dec 11 20:55:59 CST 2015
I'm sorry, but this isn't an area that the open source swift team can help with, please check with official apple channels on that.
-Chris
> On Dec 11, 2015, at 11:42 AM, James Campbell via swift-evolution <swift-evolution at swift.org> wrote:
>
> Hey Swift team can you tell the iTunes Connect team their website is down, there is no way to get a hold of them.
>
>> On Thu, Dec 10, 2015 at 10:35 PM, Josh Avant via swift-evolution <swift-evolution at swift.org> wrote:
>> Currently, when a reference-type adopts a protocol with a function declared as `mutating`, the reference-type's implementation cannot call that function internally. This is because the compiler enforces an immutable `self` pointer value, and the `mutating` qualifier implies that the function implementation may mutate that `self` pointer value.
>>
>> However, there seems to be a number of fairly reasonable situations where a reference-type implementation of these `mutating` functions may only want to mutate properties owned by `self`, but not the actual `self` pointer value.
>>
>> Consider this toy example:
>>
>> ```
>> import Foundation
>>
>> protocol RandomDataTransformable {
>> typealias TransformableType
>> var data: [TransformableType] { get set }
>>
>> mutating func addRandomData()
>> }
>>
>> extension RandomDataTransformable where TransformableType == Int {
>> mutating func addRandomData() {
>> let random = Int(arc4random_uniform(6) + 1)
>> data.append(random)
>> }
>> }
>>
>>
>> /////
>>
>> // VALID
>> struct NumberSource_Struct : RandomDataTransformable {
>> typealias TransformableType = Int
>> var data: [Int] = []
>>
>> mutating func addData() {
>> addRandomData()
>> }
>> }
>>
>>
>> // VALID
>> class NumberSource_ClassDeclaration: NSObject, RandomDataTransformable {
>> typealias TransformableType = Int
>> var data: [Int] = []
>> }
>>
>> var numberSource = NumberSource_ClassDeclaration()
>> numberSource.addRandomData()
>>
>>
>> // INVALID
>> class NumberSource_ClassImplementation: NSObject, RandomDataTransformable {
>> typealias TransformableType = Int
>> var data: [Int] = []
>>
>> func addData() {
>> self.addRandomData() // Compiler Error: Cannot use mutating member on immutable value: 'self' is immutable
>> }
>> }
>> ```
>>
>> Even despite the fact that the default implementation for `addRandomData` does not mutate the `self` pointer value, reference-type implementations are unable to call that function internally, since it is marked as `mutating`.
>>
>> Perhaps confusingly, `addRandomData` may be called by externally, by objects which own instances of the reference-type (even though, again, it may not called internally by the implementation, itself).
>>
>> Currently, the only solution to allow reference-type implementations to call the sample `addRandomData` implementation internally is to qualify the whole `RandomDataTransformable` protocol as `class`. The downside here is that this takes an otherwise perfectly reference- and struct-compatible protocol + extension implementation and restricts it to only apply to classes, decreasing overall code reusability.
>>
>> My proposal would be to introduce an intermediate mutation qualifier that applies when protocols are adopted by reference-types. The qualifier would specify that the `self` pointer value itself may not be mutated, but `self`'s properties may be, as appropriate.
>>
>> Thoughts, feedback on this?
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> --
> Wizard
> james at supmenow.com
> +44 7523 279 698
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151211/5dc23b94/attachment.html>
More information about the swift-evolution
mailing list