Multiple protocols variable - automatic class-type inference

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&gt;
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):

<img src='//cdck-file-uploads-global.s3.dualstack.us-west-2.amazonaws.com/swift/original/1X/3da4c81310a453a63640fc8bf41c580debad52a8.png' width='395' height='500'>

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.

These feel like bugs in the compiler. I'd suggest filing a bug report at http://bugs.swift.org <Issues · apple/swift · GitHub; if others don't think there is more to it...

···

On Jul 4, 2016, at 12:47 AM, Jakub Skotnicki via swift-evolution <swift-evolution@swift.org> 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&gt; 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
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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 <swift-evolution@swift.org> wrote:

These feel like bugs in the compiler. I'd suggest filing a bug report at http://bugs.swift.org <Issues · apple/swift · GitHub; if others don't think there is more to it...

On Jul 4, 2016, at 12:47 AM, Jakub Skotnicki via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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&gt; 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
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Thanks for replies, here is the use of proposed mutating function - still
does not work.

Moreover it produces weird error in 1.1A - I think it is because of
mutating keyword which cannot be used in class-protocols, but still testVar
is a class instance, so it should not matter - but if I understand you
correctly Jordan, it works in Swift 3, so no worries here?

Below - I understand this is a "let" constant, but still it should be
inferred that testVar4 and testVar5 are class instances because they
implement ClassProtocol and AnyObject protocol accordingly.
The same goes for function parameters, and now it even crashes the source
editor when uncommenting the last line.

So is this resolved in Swift 3?

···

2016-07-05 19:54 GMT+02:00 Jordan Rose <jordan_rose@apple.com>:

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 < > swift-evolution@swift.org> wrote:

These feel like bugs in the compiler. I'd suggest filing a bug report at
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 < > swift-evolution@swift.org> 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&gt;
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
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution