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

[Xiaodi Wu]

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

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

I have definitely "oned out" memory before.

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

Again, please don't do this. Dave has already explained that `init()` makes
not semantic guarantees about identity. You are reasoning backwards, and at
this point it seems you're doing this deliberately and against all reasoned
explanations as to why you're mistaken.



> 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-Mo
>>> n-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
>>>
>>
>
> _______________________________________________
> 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/63cb0355/attachment.html>