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

[Adam Nemecek]

> The all-zero bit pattern represents the integer zero—that's not the same
as whether it represents the best "default" value for an integer as a
higher-level concept, or whether such a default should exist in the first
place.

It represents a sensible value to initialize an int to when I want to
initialize an array of ints to a certain size. There is a reason why you
zero out memory but you don't "one out" memory.

> That doesn't explain why the additive identity is more special than the
multiplicative one. It just argues that it's more convenient for a
particular use case.

Because the identity associated with the default initializer as is is the
additive identity which means the default operation is addition.


On Mon, Dec 26, 2016 at 11:57 AM, Tony Allevato <tony.allevato at gmail.com>
wrote:

> On Mon, Dec 26, 2016 at 11:43 AM Adam Nemecek via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> > For integers, 0 is an additive identity. Is there a reason it should
>> be given special treatment over 1, the multiplicative identity?
>>
>> E.g. for statistical reasons. When I have a collection of users with age
>> etc it makes sense to ask what is the combined age of the collection? What
>> is the semantic meaning of multiplying their ages?
>>
>
> That doesn't explain why the additive identity is more special than the
> multiplicative one. It just argues that it's more convenient for a
> particular use case.
>
> I would turn your example around—if you're interested enough in thorough
> type design that you feel that a DefaultConstructible protocol would be
> useful here, then I offer that a better and safer design would be to create
> an "Age" value type (or, more generally, measurement types with concepts of
> units) if you want compile-time safety and limiting the supported
> operations to only those that are sensical. "Int" is arguably too wide a
> type to represent an age in a public API because it would allow two ages to
> be multiplied together, as you said.
>
>
>
>> > Mathematically, identities are associated with (type, operation) pairs,
>> not types alone.
>>
>> Correct, however we aren't talking about mathematics, we are talking
>> about the implementation of a language that runs on very concrete
>> architectures where very concrete bit patterns mean very concrete things
>> that are unlikely to change any time soon.
>>
>
> The all-zero bit pattern represents the integer zero—that's not the same
> as whether it represents the best "default" value for an integer as a
> higher-level concept, or whether such a default should exist in the first
> place.
>
>
>>
>> On Mon, Dec 26, 2016 at 11:35 AM, Tony Allevato <allevato at google.com>
>> wrote:
>>
>> For integers, 0 is an additive identity. Is there a reason it should be
>> given special treatment over 1, the multiplicative identity? Historically
>> the only reason is because it has the all-clear bit pattern.
>>
>> 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.
>> On Mon, Dec 26, 2016 at 11:27 AM Adam Nemecek via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>> The elements already have an Identity, the one that you get when you
>> invoke the default constructor. It's 0 for Int, "" for String.
>>
>> On Mon, Dec 26, 2016 at 11:24 AM, David Sweeris <davesweeris at mac.com>
>> wrote:
>>
>>
>> On Dec 26, 2016, at 11:12, Tino Heth via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>> There is an older discussion that is somewhat linked to this topic:
>> "Removing the empty initialiser requirement from
>> RangeReplaceableCollection"
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-
>> Mon-20160704/023642.html
>>
>> Imho "DefaultConstructible" types can be very handy, but so far, it seems
>> no one has presented a single use case that is important enough to justify
>> the inclusion in the stdlib.
>> On the other hand, I'm quite sure that there's much functionality in the
>> stdlib that many people consider as superfluous…
>>
>> I guess adding the protocol wouldn't have a big impact on size, so for
>> for me, the question is "Does this protocol confuse users of Swift?", which
>> I'd answer with "yes, possibly" (unless someone comes up with a name that
>> is more intuitive).
>>
>>
>> "Identity", but, at least for many numeric types, you'd need a mechanism
>> for specifying which one you mean.
>>
>> - 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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161226/85399bf1/attachment.html>