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