Just because something is simple, doesn’t mean it isn’t important. You can do a lot with ‘return
T()’ that you can’t do without it (namely make a T).Sure, but the question remains: *should* you make a T in those
circumstances? Maybe youWith DefaultConstructible, you don't know anything about the value of
this T. There is nothing you can do with it, reliably. If the default
constructability requirement is part of some larger protocol like
RangeReplaceableCollection, then you can say things like, “this makes an
empty collection,” and “a default-constructed instance is equivalent to an
instance on which you've called removeAll.” That doesn't argue for
factoring the init() out into its own protocol. It argues for including
the init() requirement in every protocol where it forms an important
part of the protocol's semantic basis operations.Ok, I think I see what you are saying now.
Equatable is similar. Semantically, it just lets you ask if two instances of the same type are
equal.Equatable is *very* different. It has a whole page of semantics. Read
from “Equality implies substitutability” to the end of the page at
http://swiftdoc.org/v3.0/protocol/Equatable/\.The fact that it only does one thing doesn’t mean it isn’t useful or
necessary as a small part of a lot of different algorithms.I find I use T() most often in factory or builder patterns, but any creational pattern may need it.
It is also often used together with other protocols. The code is all pretty boring…func hasOptionalParam( a: T = T() ) {} //The caller can pass in
a specific thing, or just leave out the parameter to use a vanilla one
orvar t = T()
t.somethingFancy() //Provided by unrelated protocol
t.moreFancy()
return tor
var t = T()
if t is SomeOtherProtocol {
//Do something fancy
}
if t is YetAnotherProtocol {
//Do something else fancy
}
return tAll of the “fancy stuff” will be done by conforming to other protocols, but those protocols may
have
nothing to do with creation (nor should they). There is nothing wrong with requiring conformance
to
multiple protocols...
No, there isn't. There *is* something wrong with slicing meaningful
protocols up into bits that have only syntactic value, though. I
suspect that's what's going on here.It’s quite possible. I kept having it in a bunch of larger protocols,
where it felt a bit tacked on and out of place, so I started factoring
it out by itself which felt cleaner.When you keep writing the same code over and over, the impulse is to
factor it out so you only write it once (and so that functions you
write need the fewest guarantees possible), but perhaps that was the
wrong instinct here...
Factoring out implementations is one thing, and definitely a good place
for DRY. Factoring out requirements should only be done when the
commonality enables some kind of generic programming. In fact, the
opposite—clustering requirements together to create concepts
(a.k.a. protocols)—is an important part of the generic programming
process. See
···
on Mon Dec 26 2016, Jonathan Hull <swift-evolution@swift.org> wrote:
On Dec 26, 2016, at 9:29 AM, Dave Abrahams via swift-evolution >> <swift-evolution@swift.org> wrote:
on Mon Dec 26 2016, Jonathan Hull > >> <swift-evolution@swift.org >> <mailto:swift-evolution@swift.org>> >> wrote:
Thanks,
JonOn Dec 26, 2016, at 7:10 AM, Xiaodi Wu >>>> <xiaodi.wu@gmail.com >>>> <mailto:xiaodi.wu@gmail.com>> wrote:
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 >>>> <jhull@gbis.com >>>> <mailto:jhull@gbis.com> >>>> <mailto:jhull@gbis.com >>>> <mailto:jhull@gbis.com>>> 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 nameAs 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,
JonOn Dec 25, 2016, at 11:28 PM, Daniel Leping via swift-evolution
<swift-evolution@swift.org
<mailto:swift-evolution@swift.org>
<mailto:swift-evolution@swift.org
<mailto:swift-evolution@swift.org>>>
wrote:It's not a matter of probability, but rather of certainty. Please.
On Mon, 26 Dec 2016 at 12:56 Xiaodi Wu
<xiaodi.wu@gmail.com
<mailto:xiaodi.wu@gmail.com>
<mailto:xiaodi.wu@gmail.com
<mailto:xiaodi.wu@gmail.com>>>
wrote:
On Mon, Dec 26, 2016 at 2:19 AM, Daniel Leping
<daniel@crossroadlabs.xyz
<mailto:daniel@crossroadlabs.xyz>
<mailto:daniel@crossroadlabs.xyz
<mailto:daniel@crossroadlabs.xyz>>>
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
<xiaodi.wu@gmail.com
<mailto:xiaodi.wu@gmail.com>
<mailto:xiaodi.wu@gmail.com
<mailto:xiaodi.wu@gmail.com>>>
wrote:
On Mon, Dec 26, 2016 at 1:48 AM, Daniel Leping
<daniel@crossroadlabs.xyz
<mailto:daniel@crossroadlabs.xyz>
<mailto:daniel@crossroadlabs.xyz
<mailto: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
<mailto:xiaodi.wu@gmail.com>
<mailto:xiaodi.wu@gmail.com
<mailto:xiaodi.wu@gmail.com>>>
wrote:
On Mon, Dec 26, 2016 at 1:21 AM, Daniel Leping
<daniel@crossroadlabs.xyz
<mailto:daniel@crossroadlabs.xyz>
<mailto:daniel@crossroadlabs.xyz
<mailto: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
<mailto:xiaodi.wu@gmail.com>
<mailto:xiaodi.wu@gmail.com
<mailto:xiaodi.wu@gmail.com>>>
wrote:
On Mon, Dec 26, 2016 at 1:10 AM, Daniel Leping
<daniel@crossroadlabs.xyz
<mailto:daniel@crossroadlabs.xyz>
<mailto:daniel@crossroadlabs.xyz
<mailto: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 <Failable Initializers - Swift Blog - Apple Developer;
<Failable Initializers - Swift Blog - Apple Developer <Failable Initializers - Swift Blog - Apple Developer;On Mon, 26 Dec 2016 at 11:38 Xiaodi Wu
<xiaodi.wu@gmail.com
<mailto:xiaodi.wu@gmail.com>
<mailto:xiaodi.wu@gmail.com
<mailto:xiaodi.wu@gmail.com>>>
wrote:
On Mon, Dec 26, 2016 at 12:58 AM, Daniel Leping
<daniel@crossroadlabs.xyz
<mailto:daniel@crossroadlabs.xyz>
<mailto:daniel@crossroadlabs.xyz
<mailto: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
<mailto:xiaodi.wu@gmail.com>
<mailto:xiaodi.wu@gmail.com
<mailto:xiaodi.wu@gmail.com>>>
wrote:
On Mon, Dec 26, 2016 at 12:50 AM, Daniel Leping
<daniel@crossroadlabs.xyz
<mailto:daniel@crossroadlabs.xyz>
<mailto:daniel@crossroadlabs.xyz
<mailto: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
<mailto:xiaodi.wu@gmail.com>
<mailto:xiaodi.wu@gmail.com
<mailto:xiaodi.wu@gmail.com>>>
wrote:
On Mon, Dec 26, 2016 at 12:43 AM, Daniel Leping via swift-evolution
<swift-evolution@swift.org
<mailto:swift-evolution@swift.org>
<mailto:swift-evolution@swift.org
<mailto: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
<mailto:swift-evolution@swift.org>
<mailto:swift-evolution@swift.org
<mailto:swift-evolution@swift.org>>>
wrote:_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
<mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
<https://lists.swift.org/mailman/listinfo/swift-evolution>--
-Dave_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
<mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
<https://lists.swift.org/mailman/listinfo/swift-evolution>_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
--
-Dave