Actually T() would definitely do the job. Thanks for pointing. A can agree it's a good replacement.
As for requiring to conform to a protocol - definitely worse solution. I was thinking of DefaultConstructable as of automatically applied protocol to anything that has init(). About "Zero" or "Identity" concept I personally tend to think of it as of a singleton static property. Also keeping in mind everything said above in the discussion these two are just different protocols. I.e. for Int "zero" could be 0 and "identity" could be 1. Identity does not feel to be the right name, though. Also, for the "zeroable" types I would rather use nil. On Tue, 27 Dec 2016 at 10:40 Braeden Profile via swift-evolution < [email protected]> wrote: > I forgot to reply to the email list here. > > On Dec 26, 2016, at 10:03 PM, Xiaodi Wu <[email protected]> wrote: > > Did you mean to reply offlist? > > Basically, a factory would be: > > func make<T>(_: T.Type) -> T { return T() } > > but you need T to conform to a protocol that guarantees T.init(). You use > it like: > > make(Foo.self) > > But one can write: > > func make<T>(_ f: @autoclosure () -> T) -> T { return f() } > > and use this like: > > make(Foo()) > > (pardon typos; freehanding on iPad) > > > > On Mon, Dec 26, 2016 at 23:58 Braeden Profile <[email protected]> > wrote: > > Actually, I’m a little lost at this point of exactly how you could build a > function with this pattern. Code, anyone? > > > On Dec 26, 2016, at 9:57 PM, Xiaodi Wu <[email protected]> wrote: > > With @autoclosure your user can simply write T() as an argument. It is > very elegant and not complicated at all. > > _______________________________________________ > > 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
