[swift-evolution] Default implementation of protocols

Xiaodi Wu xiaodi.wu at gmail.com
Mon Jan 23 19:10:00 CST 2017

This would get very confusing, as it would be impossible for a class to
distinguish conforming to protocol X vs. inheriting from base class X, or
else we would have to change the spelling for that as well. Moreover, you
would have no way of distinguishing the existential X from the struct X. I
see nothing wrong with the clarity afforded by naming the distinct things
`FooProtocol` and `Foo`, and I disagree that there's anything "simplifying"
about naming two different things with one name.

On Mon, Jan 23, 2017 at 6:13 PM, Jonathan Hull via swift-evolution <
swift-evolution at swift.org> wrote:

> Have we considered allowing a struct/class/enum to have the same name as a
> protocol as long as it conforms to the protocol?  Type declarations would
> have to always mean the protocol (which includes the concrete type as
> well).  Static functions would always apply to the concrete type.
> Seems like a good way to support having a default implementation of a
> protocol.  I am always running into the awkward naming issues around this...
>         protocol X {
>                 //yada yada
>         }
>         struct X { //Implicitly adheres to protocol X (because it must)
>                 init(){…}
>         }
>         let myVar:X //This refers to the protocol
>         let otherVar = X() //This makes the struct
> If we do need to be able to spell the concrete type for other uses, we
> could probably do something like: ‘concrete(X)’ which isn’t pretty, but is
> there for the rare times it is needed for utility.  I can’t think of any
> reason except making an array of the concrete type.
> I am guessing there is a subtle technical reason this won’t work, but I
> wanted to mention it now just in case it is possible.  Seems like it could
> have a large (simplifying) effect on the namespace of the standard library.
> Thanks,
> Jon
> _______________________________________________
> 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/20170123/5d269e31/attachment.html>

More information about the swift-evolution mailing list