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

Dave Abrahams dabrahams at apple.com
Sun Dec 25 17:17:13 CST 2016


on Sun Dec 25 2016, Xiaodi Wu <swift-evolution at swift.org> 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-Stepanov/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?

Actually we have included it in RangeReplaceableCollection because
init() + replaceSubrange() is a really powerful combination that lets
you implement things like initialization from any other collection of
the same element type.

However, though I hate to disagree with Alex, I don't really think
default constructibility is as fundamental as he says it is.  It almost
never shows up as a requirement in most algorithms I've seen, and I
don't like the idea of folding it into a standard base grouping of
requirements such as “Regular” because it effectively weakens the
invariants of the things that have to conform.  How do you
default-construct a CollectionOfOne, for example?  You can't; you'd have
to add an “invalid” state that is otherwise unnecessary.  Also, outside
of a protocol like Monoid, where it has a relationship to the operator,
there's no obvious semantics to attach to default construction.
Protocols (a.k.a. concepts) are not just bags of syntax; unless you can
attach semantics to the operations, you can't write useful generic
algorithms against them.  So we shouldn't have DefaultConstructible for
the same reason we shouldn't have “Plusable” to represent something that
lets you write x + x.

>
>
> 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
>

Cheers,

-- 
-Dave



More information about the swift-evolution mailing list