On Dec 25, 2016, at 12:54 PM, Adam Nemecek via swift-evolution <[email protected]> wrote: > Does enabling a lot of small improvements that make APIs more ergonomic count > as practical?
Yes, that would count as practical, but Xiaodi’s question is just as important. *Which* APIs become more ergonomic? Here are a couple of more questions: 1) How does this square with Swift’s general philosophy to not default initialize values to “zero”? 2) To your original example, it isn’t immediately clear to me that reduce should choose a default identity. Some types (e.g. integers and FP) belong to multiple different ring algebras, and therefore have different identity values that correspond to the relevant binary operations. -Chris > > On Sun, Dec 25, 2016 at 12:19 PM, Xiaodi Wu <[email protected] > <mailto:[email protected]>> wrote: > On Sun, Dec 25, 2016 at 3:07 PM, Adam Nemecek <[email protected] > <mailto:[email protected]>> wrote: > There's a book that provides quite a bit of info on this > > https://smile.amazon.com/Elements-Programming-Alexander-Stepanov/dp/032163537X?sa-no-redirect=1 > > <https://smile.amazon.com/Elements-Programming-Alexander-Stepanov/dp/032163537X?sa-no-redirect=1> > > They say that DefaultConstructible is one of the essential protocols on which > most algorithms rely in one way or another. One of the authors is the > designer of the C++ STL and basically the father of modern generics. > > This protocol is important for any algebraic structure that deals with the > concept of appending or addition (as "zero" is one of the requirements of > monoid). There isn't a good short answer to your question. It's a building > block of algorithms. Think about why a RangeReplaceableCollection can provide > you with a default constructor but a Collection can't. > > It's well and fine that most algorithms rely on the concept in one way or > another. Yet the Swift standard library already implements many generic > algorithms but has no DefaultConstructible, presumably because there are > other protocols that guarantee `init()` and the algorithms being implemented > don't need to be (practically speaking) generic over all DefaultConstructible > types. My question is: what practical use cases are there for an explicit > DefaultConstructible that are impractical today? > > > On Sun, Dec 25, 2016 at 11:37 AM, Xiaodi Wu <[email protected] > <mailto:[email protected]>> wrote: > Can you give some other examples of generic algorithms that would make use of > this DefaultConstructible? I'm having trouble coming up with any other than > reduce. > On Sun, Dec 25, 2016 at 14:23 Adam Nemecek via swift-evolution > <[email protected] <mailto:[email protected]>> wrote: > This protocol is present in C++ > http://en.cppreference.com/w/cpp/concept/DefaultConstructible > <http://en.cppreference.com/w/cpp/concept/DefaultConstructible> as well as in > Rust https://doc.rust-lang.org/std/default/ > <https://doc.rust-lang.org/std/default/> > > It's the identity element/unit of a monoid or a zero. > > The Swift implementation is very simple (I'm open to different names) > > protocol DefaultConstructible { > init() > } > > A lot of the standard types could then be made to conform to this protocol. > These include all the numeric types, collection types (array, set, dict), > string, basically at least every type that currently has a constructor > without any arguments. > > The RangeReplaceableCollection protocol would inherit from this protocol as > well. > > This protocol would simplify a lot of generic algorithms where you need the > concept of a zero (which shows up a lot) > > Once introduced, Sequence could define an alternative implementation of > reduce where the initial result doesn't need to be provided as it can be > default constructed. > > > > > > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <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
