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

Xiaodi Wu xiaodi.wu at gmail.com
Mon Dec 26 15:24:15 CST 2016


On Mon, Dec 26, 2016 at 3:17 PM, Adam Nemecek via swift-evolution <
swift-evolution at swift.org> wrote:

> > Array already has init(repeating:count:) that puts the responsibility
> of choosing the default value at the call site. If someone were writing a
> generic algorithm around this, then why not just propagate that
> responsibility out to its call site as well? That way, the algorithm isn't
> making any assumptions about what the "default" value is or even if one
> exists,
>
> Because encapsulation. There's a reason NSObject has a default initializer.
>

Can you elaborate? What is the reason that NSObject has a default
initializer? I suspect it has to do with Objective-C "stuff," but can you
point me to a resource explaining the rationale behind the design of
NSObject?


On Mon, Dec 26, 2016 at 12:10 PM, Tony Allevato via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> On Mon, Dec 26, 2016 at 11:57 AM David Sweeris via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>>>
>>> On Dec 26, 2016, at 11:35, Tony Allevato <allevato at google.com> wrote:
>>>
>>> Mathematically, identities are associated with (type, operation) pairs,
>>> not types alone.
>>>
>>> This conversation has put me in the column of "numeric types shouldn't
>>> have default initializers at all", personally.
>>>
>>>
>>> I'd agree, except sometimes you need a T, *any* T, for when you want to
>>> create a "pre-sized" array for stuffing results into by index:
>>> for i in ... {
>>>     a[i] = ...
>>> }
>>> Simply saying "var a =[T](); a.reserveCapacity()" doesn't cut it because
>>> it'll still crash if you try to store anything in a[i] without somehow
>>> putting at least i+1 elements in the array first.
>>>
>>
>> Array already has init(repeating:count:) that puts the responsibility of
>> choosing the default value at the call site. If someone were writing a
>> generic algorithm around this, then why not just propagate that
>> responsibility out to its call site as well? That way, the algorithm isn't
>> making any assumptions about what the "default" value is or even if one
>> exists, and it doesn't impose additional requirements on the element type.
>> For example, the user could get the default from a static factory method,
>> an instance method on another object, or something else entirely.
>>
>>
>>
>>>
>>> - Dave Sweeris
>>> _______________________________________________
>>> 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
>>
>>
>
> _______________________________________________
> 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/20161226/c2e7a319/attachment.html>


More information about the swift-evolution mailing list