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 < [email protected]> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
