[swift-evolution] [Pitch] Add the DefaultConstructible protocol to the standard library

[Daniel Leping]

I'm not against explicit protocol conformance for custom stuff, but doesn't
default constructor look like a very common use case?

Again, I'm completely against implicit conformance for custom stuff, but
this one is of the same level as AnyObject implicit conformance. It's an
exception, isn't it? Why can't we do the same for DefaultConstructable
which is the case for most classes/structs?

As for the Spring-like DIs. I have some experience implementing such in C++
and yes, this feature is mandatory to get one in Swift without any use of
advanced reflection.

Seriously, I want to have a capability in generic functions to restrict
parameters to DefultConstructable and factories is an obvious use case.
Hope it's very clear why.

On Mon, 26 Dec 2016 at 10:51 Xiaodi Wu <xiaodi.wu at gmail.com> wrote:

> On Mon, Dec 26, 2016 at 12:05 AM, Daniel Leping <daniel at crossroadlabs.xyz>
> wrote:
>
> This is a very old discussion that took plays years ago with POJO vs
> JavaBean approach. For sure, extensions give us a bit more flexibility,
> though the subject remains the same.
>
> Extensions are not a panacea and I think we should always look back for
> good proven patterns rather than reinvent the wheel.
>
> Also, consider SpringFramework-like solution in Swift. How would you deal
> with object factories without DefaultConstructable in an elegant way?
>
>
> Without being extremely familiar with this area, I'd imagine it would
> depend on more advanced reflection facilities in any case, which are a
> topic for future versions of Swift. Moreover, in a language where immutable
> value types are idiomatic, `init()` wouldn't help you there at all, and
> you'll have to be working with code written in a very different way anyway.
> So I guess I'm not sure why conforming to a protocol explicitly (and
> retroactively, if necessary) is what's standing in the way of whatever
> solution you're reaching for.
>
>
> Also, I have some plans to work on one soon, so I consider this topic
> quite some important.
>
>
>
>
> On Mon, 26 Dec 2016 at 10:25 Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
> On Sun, Dec 25, 2016 at 11:52 PM, Daniel Leping <daniel at crossroadlabs.xyz>
> wrote:
>
> Ok, which approach is easier? Plain struct working out of the box or
> adding an additional conformance? I like the usage be as easy as possible
> and as less effort as possible.
>
>
> I'd say `class Foo { ... }` and `class Foo : Model { ... }` are equal in
> ease and effort.
>
> On Mon, 26 Dec 2016 at 10:20 Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
> On Sun, Dec 25, 2016 at 11:46 PM, Daniel Leping <daniel at crossroadlabs.xyz>
> wrote:
>
> You are right, usually it's required to implement a protocol which is not
> a good approach.
>
>
> Why is it not?
>
>
> The best is plain objects which can be used independently of ORM if needed
> (as DTOs, i.e.).
>
>
> An object that conforms to some protocol can still be used independently
> of the ORM solution!
>
> I was thinking of DefaultConstructable as a protocol automatically applied
> to any class/struct having a default init, which is really logical for me.
>
>
>
> On Mon, 26 Dec 2016 at 9:41 Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
> On Sun, Dec 25, 2016 at 10:50 PM, Daniel Leping <daniel at crossroadlabs.xyz>
> wrote:
>
> Ok, an example from ORM. You have an entity factory with a virtual (read,
> overloadable in the subclasses) method populating the properties.
> DefaultConstructable is a great choice here. Otherwise you will have to
> force the users of your ORM to implement a certain protocol, which you most
> probably would like to avoid.
>
>
> Sorry--I'm not very familiar with using Swift for ORM purposes. Why do you
> want to avoid having your users conform to a certain protocol? Wouldn't the
> users of your ORM have to conform to `DefaultConstructible` then? I'm
> looking at Swift ORMs, and all require users to conform to a protocol or
> inherit from a base class, typically named `Model` or similar. From a quick
> Google search:
>
> https://vapor.github.io/documentation/fluent/model.html
> https://github.com/blitzagency/amigo-swift
>
>
> In general I think the best showcase is generic factories.
>
> On Mon, 26 Dec 2016 at 9:02 Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
> On Sun, Dec 25, 2016 at 10:18 PM, Daniel Leping <daniel at crossroadlabs.xyz>
> wrote:
>
> Usually it's a generic function that needs to return a value from some
> other function or a default value (zero) in a case of some conditions.
> Optional value is an arguable solution in quite some scenarios. Afaik,
> sometimes it can be used for optional resolution.
>
>
> Right, I'd agree that Optional is the idiomatic way to do it. Afaict,
> there's not much you can do with a default value that you couldn't with
> nil, unless you have some guarantee as to _what_ that default is; however,
> I'd expect that in every case that you can rely on a guarantee about a
> default value which would be more useful than nil, it's going to require
> more specific knowledge of your type than an all-encompassing
> `DefaultConstructible` can provide.
>
> Also, generic factories. Widely used in ORM solutions.
>
>
> Can you elaborate on this? Why is Optional not a solution here?
>
>
> As mentioned above, algorythmical stuff that requires Zero.
>
>
> I'm still not convinced there exist credible use cases that need to be
> generic over both collections and floating point, for instance. In fact, in
> my experience, there are few math-heavy algorithms where one can ignore
> even the distinction between integers and binary floating point. By the
> time you get down to matrix math, you start to run into difficulties that
> require separate implementations for Float and Double.
>
> On Mon, 26 Dec 2016 at 8:38 Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
> Can you give some examples of what you used this approach to do?
>
>
> On Sun, Dec 25, 2016 at 9:49 PM, Daniel Leping <daniel at crossroadlabs.xyz>
> wrote:
>
> +1 to this approach. I remember I had to create it on my own for my
> projects. Would be nice to have it out of the box.
>
> On Mon, 26 Dec 2016 at 8:11 Adam Nemecek via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> > Yes, those particular types have initializers that take no arguments.
> That does not address my question. You merely restated your initial
> observation that many types in Swift have implemented `init()`.
>
> Right, it's an empirical argument.
>
> > I didn't think the value returned by `init()` was regarded as any sort
> of zero--or even any sort of "default." In fact, some types in Foundation
> have a static property called `default` distinct from `init()`.
>
> Let's not talk about those then. This would not apply to every single type
> in existence, as I've stated previously.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161226/8d54d271/attachment.html>