[SG16-Unicode] [isocpp-lib-ext] Proposed design change to P1030 filesystem::path_view
Andrew Tomazos
andrewtomazos at gmail.com
Wed Aug 28 12:56:28 CEST 2019
On Wed, Aug 28, 2019 at 8:16 PM Ville Voutilainen <
ville.voutilainen at gmail.com> wrote:
> On Wed, 28 Aug 2019 at 07:18, Andrew Tomazos via Lib-Ext
> <lib-ext at lists.isocpp.org> wrote:
> >
> > I think modelling a path as a container of its components is reasonable.
> >
> > What isn't reasonable is that those components are themselves paths, as
> this would imply that the value of a single-component path P is a container
> of one item, and that one item contained in P has the value P. A container
> shouldn't be able to contain itself. It's nonsensical.
>
> It's perfectly sensical for hierarchical things
Consider:
struct Tree {
std::vector<Tree> children;
};
bool operator==(const Tree& a, const Tree& b) {
return a.children == b.children;
}
Here we have a type that is a container of itself. A hierarchy.
However, there is no *value* of type Tree such that:
*this == this->children[0]
I would argue hierarchy alone is not a sufficient motivation to have a
self-referential model such that a *value* can be a container holding
itself.
You would need to be modelling something that needs a cyclic directed graph
- but even then we don't often think of a graph node as being a "container"
of its outbound edges.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.open-std.org/pipermail/unicode/attachments/20190828/0af8586f/attachment.html
More information about the Unicode
mailing list