[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