> On Aug 16, 2016, at 6:51 PM, Slava Pestov via swift-evolution > <[email protected]> wrote: > >> I am a little concerned about the second requirement. Protocols that include >> static methods and initializers work perfectly well inside arrays, and >> restricting them from generic collections will further discourage use of the >> latter in favor of the former. > > Here is why we must have that requirement. Consider the following code: > > protocol P { > init() > } > > struct A : P { > init() {} > } > > struct B : P { > init() {} > } > > func makeIt<T : P>() -> T { > return T() > } > > I can use this function as follows: > > let a: A = makeIt() // Creates a new ‘A' > let a: B = makeIt() // Creates a new ‘B’ > > Now suppose we allow P to self-conform. Then the following becomes valid: > > let p: P = makeIt() > > What exactly would makeIt() do in this case? There’s no concrete type passed > in, or any way of getting one, so there’s nothing to construct. The same > issue would come up with static methods here.
Could we mark the generic parameter with an attribute which basically means "I will not call static members of this type except through a `type(of:)` call"? For that matter, should we just do that by default? It seems like in most cases where we don't somehow pass an instance of the type, we end up passing an instance of its metatype anyway. See, for instance, `unsafeBitCast(_:to:)`, which takes an instance of the metatype which is technically redundant, but helps pin down the return type. Anything you might need to do with `U.self` could instead be done with `to`. -- Brent Royal-Gordon Architechies _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
