Moreover, how would you extend the protocol? On Mon, Jan 23, 2017 at 19:51 Xiaodi Wu <[email protected]> wrote:
> No, I don't think so. How would you declare a variable of type X, meaning > the protocol? > On Mon, Jan 23, 2017 at 19:49 Jonathan Hull <[email protected]> wrote: > > I agree with your point on classes, so maybe just value types would be > allowed to do it (I have only wanted it for structs myself). I think I > answered your comment about distinguishing between existential and struct X > if you re-read my original message. > > Thanks, > Jon > > On Jan 23, 2017, at 5:10 PM, Xiaodi Wu <[email protected]> wrote: > > 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
