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.
···
On Mon, 26 Dec 2016 at 12:32 Xiaodi Wu <xiaodi.wu@gmail.com> wrote:
On Mon, Dec 26, 2016 at 1:48 AM, Daniel Leping <daniel@crossroadlabs.xyz> > 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 <xiaodi.wu@gmail.com> wrote:
On Mon, Dec 26, 2016 at 1:21 AM, Daniel Leping <daniel@crossroadlabs.xyz> > 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 <xiaodi.wu@gmail.com> wrote:
On Mon, Dec 26, 2016 at 1:10 AM, Daniel Leping <daniel@crossroadlabs.xyz> > 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." <
Failable Initializers - Swift Blog - Apple Developer;On Mon, 26 Dec 2016 at 11:38 Xiaodi Wu <xiaodi.wu@gmail.com> wrote:
On Mon, Dec 26, 2016 at 12:58 AM, Daniel Leping <daniel@crossroadlabs.xyz> > 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 <xiaodi.wu@gmail.com> wrote:
On Mon, Dec 26, 2016 at 12:50 AM, Daniel Leping <daniel@crossroadlabs.xyz> > 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 <xiaodi.wu@gmail.com> wrote:
On Mon, Dec 26, 2016 at 12:43 AM, Daniel Leping via swift-evolution < > swift-evolution@swift.org> 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 < > swift-evolution@swift.org> wrote:
> Swift doesn't do implicit conformance. It always has to be declared
explicitly. I'm pretty sure Doug Gregor can explain why better than I
could.I don't think Daniel was arguing for implicit conformance, he's saying
that if it makes sense for an object to have a default constructor, it
makes sense for it to conform to the protocol which I agree with 100%.On Sun, Dec 25, 2016 at 9:17 PM, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote:
on Sun Dec 25 2016, Daniel Leping <swift-evolution@swift.org> wrote:
> You are right, usually it's required to implement a protocol which is
not a> good approach. The best is plain objects which can be used independently
of> ORM if needed (as DTOs, i.e.).
>
> I was thinking of DefaultConstructable as a protocol automatically
applied> to any class/struct having a default init, which is really logical for
> me.
Swift doesn't do implicit conformance. It always has to be declared
explicitly. I'm pretty sure Doug Gregor can explain why better than I