On Mon, Dec 26, 2016 at 11:43 AM Adam Nemecek via swift-evolution < [email protected]> 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 <[email protected]> > 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 < > [email protected]> 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 <[email protected]> > wrote: > > > On Dec 26, 2016, at 11:12, Tino Heth via swift-evolution < > [email protected]> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
