[swift-evolution] [Pitch] Require Any for existentials

Adrian Zubarev adrian.zubarev at devandartist.com
Tue Aug 23 17:14:07 CDT 2016


The basic design is fine, but I wouldn't want to add more noise to my code. We could keep (label: Protocol) as a shorthand form for (label: Any<Protocol>) similar to Optionals.  

What's the benifite of this anywasys? What exactly will this solve?!  

--  
Adrian Zubarev
Sent with Airmail  

Am 23. August 2016 um 23:18:35, Chris Lattner via swift-evolution (swift-evolution at swift.org(mailto:swift-evolution at swift.org)) schrieb:

>  
> On Aug 23, 2016, at 1:49 PM, Anton Zhilin via swift-evolution <swift-evolution at swift.org> wrote:
> > I haven't yet prepared a formal proposal, but the idea should be understood by pretty much everyone. This topic has been discussed, but deferred to "post-Swift3". I think the time for it has come.
>  
> Hi Anton,
>  
> This is a source breaking change, and we don’t have a framework established for how to handle those in the post-swift 3 world yet. The core team is focusing on finishing up Swift 3 right now, but I expect that one of the first topics will be to define and iterate on the model for handling source changes.
>  
> Only once that is established can we determine whether a proposal like this is possible and know what the tradeoffs are that it entails.
>  
> -Chris
>  
>  
> >  
> > Basically, the proposal is to make protocols non-types. To use protocol as an existential type, it must be wrapped in Any:
> >  
> > protocol ExampleProtocol {
> > func foo() -> Int
> > func bar() -> String
> > }
> >  
> > func f<T: ExampleProtocol>() // OK
> >  
> > func f(x: ExampleProtocol) // error: ExampleProtocol is not a type
> > func f(x: Any<ExampleProtocol>) // OK
> >  
> > This will syntactically separate existential types from protocols themselves and generic constraints.
> > The proposal does not allow for much variativity, and it looks like the proposal can be easily created and submitted.
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>  
> _______________________________________________
> 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/20160824/20efec7a/attachment.html>


More information about the swift-evolution mailing list