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