The question still remains unanswered, what generic algorithms are enabled by having such a protocol? After a long chain, the answer so far is `return T()`. Indeed, afaict, the semantics you are proposing would explicitly limit us to that.
On Mon, Dec 26, 2016 at 09:32 Jonathan Hull <[email protected]> wrote: > My two cents: > 1) T() should NOT have anything to do with zero or even “default". (If we > need semantic zero, create a protocol with a .zero static func/var) > 2) This comes up enough in my programming, and is such a fundamental > concept, that T() probably DOES deserve special treatment in the form of a > protocol > 3) The semantics of that protocol would be “Things which can be created > without any additional information beyond their Type” > 4) We should keep working on the name > > As to whether the protocol needs to be implicit… I am unsure. It may be > enough to have the standard library + cocoa types conform where > appropriate. On the other hand, I can’t think of any type having T() which > would not fit the above semantics… and I would guess around 85~90% of types > have it, so it may be worth the trouble to make it implicit in this > specific case. I am on the fence, but would probably lean against making > it implicit. > > Thanks, > Jon > > > On Dec 25, 2016, at 11:28 PM, Daniel Leping via swift-evolution < > [email protected]> wrote: > > It's not a matter of probability, but rather of certainty. Please. > > On Mon, 26 Dec 2016 at 12:56 Xiaodi Wu <[email protected]> wrote: > > On Mon, Dec 26, 2016 at 2:19 AM, Daniel Leping <[email protected]> > wrote: > > I totally agree Swift is an opinionated language and it's good. > > Also I have been thinking of DefaultConstructable vs reflection for > generic factories and I would prefer to stick to the protocol as it gives > compile time type safety check. With reflection the only way is to through > an exception if there is no init. So again +1 pro to DefaultConstructable. > > > Well, you can't argue both ways. Either so many types implement `init()` > that it is unusually onerous to type, in which case you will gain nearly > nothing from compile-time checks, or not so many types implement `init()`, > and you can conform those types to a protocol by yourself :) > > > On Mon, 26 Dec 2016 at 12:32 Xiaodi Wu <[email protected]> wrote: > > On Mon, Dec 26, 2016 at 1:48 AM, Daniel Leping <[email protected]> > wrote: > > Well, AnyObject exists on Linux with no bridging. Still it's IMPLICITELY > conformed by all classes. > > What you say is just another approach to the same issue and we can argue > for eternity. However, I am very positive with syntactic sugar and this one > falls exactly to sugar category. Make people lifes easier ;) > > Moreover it will never ever do any harm. > > Adding an easy way to get another set of frameworks/approaches/etc (proven > by time, btw) on board sounds very appealing to me. I wish to see Swift a > very diverse ecosystem and this Pitch serves exactly this goal. > > > Yes, we should let others chime in on this issue. I will just end by > saying that I've always appreciated how the core team has been very careful > and thoughtful about certain precepts, and how they've stuck to the idea > that Swift is an _opinionated_ language. > > In particular, I appreciate that there's a huge amount of thought put into > semantic meaning. The notion that protocols should carry semantics has been > adhered to very strictly. This is why I think this proposal does do harm, > because it explicitly rejects that very important idea, one that can only > be upheld by people and not compilers. > > (Another semantic distinction observed in Swift is that a boolean value > has semantic meaning and is not just a bit; this is why, for instance, the > FloatingPoint protocols define an `enum FloatingPointSign { case plus, > minus }`--because floating point sign has different _semantics_ from a > Bool.) > > Let's just see if it gets any more positive votes. > > On Mon, 26 Dec 2016 at 12:10 Xiaodi Wu <[email protected]> wrote: > > On Mon, Dec 26, 2016 at 1:21 AM, Daniel Leping <[email protected]> > wrote: > > I believe you're confusing in-class factory methods with factory pattern. > > Factories can be separate objects and it's a very different situation. > > > Fair, but I understand both to fall under the umbrella of "any factory > pattern" and just wanted to point out that at least some of those patterns > seem to be discouraged :) > > In any case, I think it's fair to say that the question "does this type > implement `init()`?" is properly a reflection question and not a protocol > conformance question: the answer provides no semantic guarantees whatsoever > about the value that you get from `init()`, and in your use case you do not > care and simply want to invoke the initializer and return what you get from > it. Now, in a perfect world where the reflection facilities that Swift > provided were essentially free of performance cost, would you object to > that characterization? > > You're certainly right that `AnyObject` has magic. It's rather obvious > that Obj-C bridging is non-negotiable for Swift, and of course a bridged > type is all sorts of different under the hood from a native type. I'm going > to take a wild guess that no other use case would pass that high bar for > magic. > > > On Mon, 26 Dec 2016 at 11:46 Xiaodi Wu <[email protected]> wrote: > > On Mon, Dec 26, 2016 at 1:10 AM, Daniel Leping <[email protected]> > wrote: > > I'm giving a wider range, which is about ANY factory pattern related > stuff. Doesn't look to be narrow to me. > > > I thought factory methods were regarded as undesirable in Swift? One of > the stated reasons for failable initializers was: "Failable initializers > eliminate the most common reason for factory methods in Swift... Using the > failable initializer allows greater use of Swift’s uniform construction > syntax, which simplifies the language by eliminating the confusion and > duplication between initializers and factory methods." < > https://developer.apple.com/swift/blog/?id=17> > > > On Mon, 26 Dec 2016 at 11:38 Xiaodi Wu <[email protected]> wrote: > > On Mon, Dec 26, 2016 at 12:58 AM, Daniel Leping <[email protected]> > wrote: > > Well, reflection is a huge performance drop. Protocol conformance is way > better. > > > I'm not sure how huge it would be in the grand scheme of things; in your > example, you are still evaluating a train of protocol conformances and > casting at runtime. Of course, compiler magic can be fast, but I still > don't see how this is a "very common use case" (as you write) that would > justify magic equivalent to that for Objective-C bridging, which is what > you're saying it should be. If `DefaultConstructible` is useful only when > it's magic and the specific use case is dependency injection/inversion of > control, then we're getting very specialized here. > > > On Mon, 26 Dec 2016 at 11:26 Xiaodi Wu <[email protected]> wrote: > > On Mon, Dec 26, 2016 at 12:50 AM, Daniel Leping <[email protected]> > wrote: > > I'm not arguing for implicit conformance in general, but I'm telling that > DefaultConstructable is the same basic level as AnyObject, which is > conformed implicitly. > > Shortly, I'm against implicit conformance in general. I'm positive with > "automatic compiler magic" conformance to DefaultConstructable for any > object having a default constructor as it really is a very basic stuff. > Otherwise you will have to add explicit conformance to it in almost every > class of yours (annoying). > > > Well, this sounds very different from Adam's proposal, where he proposes > semantic meaning for `init()` that, as he described, means that it cannot > apply to every type that implements `init()`. However, he also just said > that he thinks that all types with `init()` should conform, so I guess I'm > confused which way that is. > > At base, you want a way of knowing if a type has `init()`. That sounds > like reflection to me, not protocol conformance. For the record, I look > forward to the day when AnyObject magic is removed; I assume it is coming > eventually. > > > On Mon, 26 Dec 2016 at 11:14 Xiaodi Wu <[email protected]> wrote: > > On Mon, Dec 26, 2016 at 12:43 AM, Daniel Leping via swift-evolution < > [email protected]> wrote: > > Thank you, Adam! > > > Wait, are you arguing for implicit conformance or not? > > On Mon, 26 Dec 2016 at 11:12 Adam Nemecek via swift-evolution < > [email protected]> wrote: > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
