[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