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

[Tony Allevato]

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/d6c28145/attachment.html>