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=1They 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?
Actually we have included it in RangeReplaceableCollection because
init() + replaceSubrange() is a really powerful combination that lets
you implement things like initialization from any other collection of
the same element type.
However, though I hate to disagree with Alex, I don't really think
default constructibility is as fundamental as he says it is. It almost
never shows up as a requirement in most algorithms I've seen, and I
don't like the idea of folding it into a standard base grouping of
requirements such as “Regular” because it effectively weakens the
invariants of the things that have to conform. How do you
default-construct a CollectionOfOne, for example? You can't; you'd have
to add an “invalid” state that is otherwise unnecessary. Also, outside
of a protocol like Monoid, where it has a relationship to the operator,
there's no obvious semantics to attach to default construction.
Protocols (a.k.a. concepts) are not just bags of syntax; unless you can
attach semantics to the operations, you can't write useful generic
algorithms against them. So we shouldn't have DefaultConstructible for
the same reason we shouldn't have “Plusable” to represent something that
lets you write x + x.
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.This protocol is present in C++ http://en.cppreference.com
/w/cpp/concept/DefaultConstructible as well as in Rust
std::default - RustIt'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
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Cheers,
···
on Sun Dec 25 2016, Xiaodi Wu <swift-evolution@swift.org> wrote:
On Sun, Dec 25, 2016 at 3:07 PM, Adam Nemecek > <adamnemecek@gmail.com> wrote:
On Sun, Dec 25, 2016 at 11:37 AM, Xiaodi Wu <xiaodi.wu@gmail.com> > wrote:On Sun, Dec 25, 2016 at 14:23 Adam Nemecek via swift-evolution < >>> swift-evolution@swift.org> wrote:
--
-Dave