The case with testVar4 and testVar5 is not exactly a bug—the default 
implementation of a mutating protocol requirement can reassign 'self' even if 
the dynamic type turns out to be a class. (I'm not sure that's a good feature, 
but it is the current behavior of Swift 3.) I agree that we should resolve the 
contradiction at the end somehow, though.

Jordan


> On Jul 5, 2016, at 8:39, Charlie Monroe via swift-evolution 
> <[email protected]> wrote:
> 
> These feel like bugs in the compiler. I'd suggest filing a bug report at 
> http://bugs.swift.org <http://bugs.swift.org/> if others don't think there is 
> more to it...
> 
>> On Jul 4, 2016, at 12:47 AM, Jakub Skotnicki via swift-evolution 
>> <[email protected] <mailto:[email protected]>> wrote:
>> 
>> Hi,
>> 
>> I would like to make a proposal for automatic class-type inference for a 
>> variable which conforms to multiple protocols. I have not seen any similar 
>> proposals on swift-evolution <https://github.com/apple/swift-evolution> 
>> site, also these in the rejected section, that is why I am mailing it to 
>> discuss. 
>> 
>> What is it about? (picture below - code with explanations):
>> 
>> <swift.png>
>> 
>> Conclusion:
>> Multiple protocols constant variable should have its properties mutable if 
>> at least one of the protocols is a class-protocol. Firstly, this solves a 
>> problem of changing this variable to mutable (with var keyword), which can 
>> simply be undesirable, and currently leads to a paradox warning if done on a 
>> method parameter. Secondly, it solves a problem of changing specified 
>> protocols to class-protocols in order to modify any properties or use 
>> mutating function on such variables, which could be an unwanted constrain or 
>> it is simply impossible in cases where specified protocols iare also 
>> implemented by non-class types.
>> 
>> I believe it has no impact on existing code. It will simply start to work.
>> 
>> Please let me know what you think about it.
>> _______________________________________________
>> swift-evolution mailing list
>> [email protected] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to