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

[Adam Nemecek]

> *Which* APIs become more ergonomic?

I'll get back to this question in a second if I may. This would be a longer
discussion and I first want to make sure that before we get into the
details that there is a possibility of this being introduced (I'm asking if
violating the no zero defaults is more important than slightly more
ergonomic APIs). But to give a broad answer I think that the concept of a
zero is closely related to the concept of equality (and all the things that
build up on equality such as comparability and negation).

> 1) How does this square with Swift’s general philosophy to not default
initialize values to “zero”?

I actually wasn't aware of this philosophy. Despite this philosophy, look
at how many types actually currently implement a default constructor. Also
can I ask what's the motivation behind this philosophy?
I think that in Swift, default constructibility makes complete sense for
(most?) structs, maybe less so for classes.

> 2) To your original example, it isn’t immediately clear to me that reduce
should choose a default identity.  Some types (e.g. integers and FP) belong
to multiple different ring algebras, and therefore have different identity
values that correspond to the relevant binary operations.

This is a good point that I've considered as well but felt that for the
most part, there is one particular identity and associated operation that
is more prominent and useful than others. Furthermore, modeling different
algebras isn't mutually exclusive with writing generic algorithms that rely
on this protocol, you can always introduce some monoidic wrapper type that
defines the more appropriate default value and operation.


On Sun, Dec 25, 2016 at 1:24 PM, Chris Lattner <clattner at apple.com> wrote:

> On Dec 25, 2016, at 12:54 PM, Adam Nemecek via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> Does enabling a lot of small improvements that make APIs more ergonomic
> count as practical?
>
>
> Yes, that would count as practical, but Xiaodi’s question is just as
> important.  *Which* APIs become more ergonomic?
>
> Here are a couple of more questions:
>
> 1) How does this square with Swift’s general philosophy to not default
> initialize values to “zero”?
>
> 2) To your original example, it isn’t immediately clear to me that reduce
> should choose a default identity.  Some types (e.g. integers and FP) belong
> to multiple different ring algebras, and therefore have different identity
> values that correspond to the relevant binary operations.
>
> -Chris
>
>
> On Sun, Dec 25, 2016 at 12:19 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
>> On Sun, Dec 25, 2016 at 3:07 PM, Adam Nemecek <adamnemecek at gmail.com>
>> wrote:
>>
>>> There's a book that provides quite a bit of info on this
>>>
>>> https://smile.amazon.com/Elements-Programming-Alexander-Step
>>> anov/dp/032163537X?sa-no-redirect=1
>>>
>>> They say that DefaultConstructible is one of the essential protocols on
>>> which most algorithms rely in one way or another. One of the authors is the
>>> designer of the C++ STL and basically the father of modern generics.
>>>
>>> This protocol is important for any algebraic structure that deals with
>>> the concept of appending or addition (as "zero" is one of the requirements
>>> of monoid). There isn't a good short answer to your question. It's a
>>> building block of algorithms. Think about why a RangeReplaceableCollection
>>> can provide you with a default constructor but a Collection can't.
>>>
>>
>> It's well and fine that most algorithms rely on the concept in one way or
>> another. Yet the Swift standard library already implements many generic
>> algorithms but has no DefaultConstructible, presumably because there are
>> other protocols that guarantee `init()` and the algorithms being
>> implemented don't need to be (practically speaking) generic over all
>> DefaultConstructible types. My question is: what practical use cases are
>> there for an explicit DefaultConstructible that are impractical today?
>>
>>
>> On Sun, Dec 25, 2016 at 11:37 AM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>>>
>>>> Can you give some other examples of generic algorithms that would make
>>>> use of this DefaultConstructible? I'm having trouble coming up with any
>>>> other than reduce.
>>>> On Sun, Dec 25, 2016 at 14:23 Adam Nemecek via swift-evolution <
>>>> swift-evolution at swift.org> wrote:
>>>>
>>>>> This protocol is present in C++ http://en.cppreference.com
>>>>> /w/cpp/concept/DefaultConstructible as well as in Rust
>>>>> https://doc.rust-lang.org/std/default/
>>>>>
>>>>> It's the identity element/unit of a monoid or a zero.
>>>>>
>>>>> The Swift implementation is very simple (I'm open to different names)
>>>>>
>>>>> protocol DefaultConstructible {
>>>>>     init()
>>>>> }
>>>>>
>>>>> A lot of the standard types could then be made to conform to this
>>>>> protocol. These include all the numeric types, collection types (array,
>>>>> set, dict), string, basically at least every type that currently has a
>>>>> constructor without any arguments.
>>>>>
>>>>> The RangeReplaceableCollection protocol would inherit from this
>>>>> protocol as well.
>>>>>
>>>>> This protocol would simplify a lot of generic algorithms where you
>>>>> need the concept of a zero (which shows up a lot)
>>>>>
>>>>> Once introduced, Sequence could define an alternative implementation
>>>>> of reduce where the initial result doesn't need to be provided as it can be
>>>>> default constructed.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> swift-evolution mailing list
>>>>> swift-evolution at swift.org
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>>
>>>>
>>>
>>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161225/74166225/attachment.html>