Re: [swift-evolution] Will existentials ever conform to their protocols?

[Joe Groff via swift-evolution]

> On Jan 18, 2017, at 12:10 AM, Anton Zhilin via swift-evolution 
>  wrote:
> 
> There is also a caveat with static members:
> 
> protocol P {
> static func foo()
> }
> 
> struct S : P {
> static func foo() { }
> }
> 
> func bar(x: T) {
> T.foo()
> }
> 
> let p = S() as P
> bar(p)  // P.foo() does not exist

Right, part of the language design problem here is that not every protocol type 
is naturally a model of its protocol. In addition to static members, if you 
have any "Self" arguments in your method requirements, you wouldn't naturally 
be able to use those requirements, which expect a specific type modeling the 
protocol, on the type-erased protocol type. For many protocols, there's an 
obvious generalization—to compare two Equatables, first check that they're the 
same type, then call the == on the values of that type; for factory protocols 
with initializer requirements, there may be a reasonable default implementation 
type to provide if you ask to construct a P(). We'd want a way to provide that 
self-conformance if it doesn't fall out naturally from generalizing the 
protocol requirements.

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

Re: [swift-evolution] Will existentials ever conform to their protocols?

[Slava Pestov via swift-evolution]

Yes, there’s already logic to detect and diagnose this case in fact (@objc 
protocols are self-conforming, except when they contain static members or 
initializers).

Slava

> On Jan 18, 2017, at 12:10 AM, Anton Zhilin via swift-evolution 
>  wrote:
> 
> There is also a caveat with static members:
> 
> protocol P {
> static func foo()
> }
> 
> struct S : P {
> static func foo() { }
> }
> 
> func bar(x: T) {
> T.foo()
> }
> 
> let p = S() as P
> bar(p)  // P.foo() does not exist
> ___
> 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

Re: [swift-evolution] Will existentials ever conform to their protocols?

[Anton Zhilin via swift-evolution]

There is also a caveat with static members:

protocol P {
static func foo()
}

struct S : P {
static func foo() { }
}

func bar(x: T) {
T.foo()
}

let p = S() as P
bar(p)  // P.foo() does not exist

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

Re: [swift-evolution] Will existentials ever conform to their protocols?

[Slava Pestov via swift-evolution]

> On Jan 17, 2017, at 9:33 PM, David Sweeris via swift-evolution 
>  wrote:
> 
> 
> On Jan 17, 2017, at 22:30, Braeden Profile via swift-evolution 
> > wrote:
> 
>> Hello Swift Community!
>> 
>> I know that I’ve seen this mentioned before, but what with Enhanced 
>> Existentials being brought up, I think this is worth mentioning now.  What 
>> is the plan regarding letting existentials conform to their protocols?  
>> Currently, in Swift 3, it is impossible to write code like this:
>> protocol Updatable
>>  { func update() }
>> 
>> struct UpdatePool
>>  { /* ... */ }
>> 
>> let heterogenousPool = UpdatePool()
>> Error on the last line:  “Using ‘Updatable’ as a concrete type conforming to 
>> protocol ‘Updatable’ is not supported.”
>> 
>> 
>> Although my most common use case of this behavior has actually been solved 
>> (using ‘AnyObject’ as a concrete type conforming to ‘AnyObject’), I wonder 
>> why this can’t be extended to any protocol existential (a field which is 
>> about to explode, if we succeed in Enhancing them).
>> 
>> What do you guys think?
> 
> +1, but I think there's a compiler limitation preventing it at the moment.

See my recent post: 
https://www.mail-archive.com/swift-users@swift.org/msg03427.html

Slava


> 
> - Dave Sweeris 
> ___
> 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

Re: [swift-evolution] Will existentials ever conform to their protocols?

[David Sweeris via swift-evolution]

> On Jan 17, 2017, at 22:30, Braeden Profile via swift-evolution 
>  wrote:
> 
> Hello Swift Community!
> 
> I know that I’ve seen this mentioned before, but what with Enhanced 
> Existentials being brought up, I think this is worth mentioning now.  What is 
> the plan regarding letting existentials conform to their protocols?  
> Currently, in Swift 3, it is impossible to write code like this:
> protocol Updatable
>   { func update() }
> 
> struct UpdatePool
>   { /* ... */ }
> 
> let heterogenousPool = UpdatePool()
> Error on the last line:  “Using ‘Updatable’ as a concrete type conforming to 
> protocol ‘Updatable’ is not supported.”
> 
> 
> Although my most common use case of this behavior has actually been solved 
> (using ‘AnyObject’ as a concrete type conforming to ‘AnyObject’), I wonder 
> why this can’t be extended to any protocol existential (a field which is 
> about to explode, if we succeed in Enhancing them).
> 
> What do you guys think?

+1, but I think there's a compiler limitation preventing it at the moment.

- Dave Sweeris ___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Will existentials ever conform to their protocols?

[Braeden Profile via swift-evolution]

Hello Swift Community!

I know that I’ve seen this mentioned before, but what with Enhanced 
Existentials being brought up, I think this is worth mentioning now.  What is 
the plan regarding letting existentials conform to their protocols?  Currently, 
in Swift 3, it is impossible to write code like this:
protocol Updatable
{ func update() }

struct UpdatePool
{ /* ... */ }

let heterogenousPool = UpdatePool()
Error on the last line:  “Using ‘Updatable’ as a concrete type conforming to 
protocol ‘Updatable’ is not supported.”


Although my most common use case of this behavior has actually been solved 
(using ‘AnyObject’ as a concrete type conforming to ‘AnyObject’), I wonder why 
this can’t be extended to any protocol existential (a field which is about to 
explode, if we succeed in Enhancing them).

What do you guys think?

—Braeden Hintze___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution