C++ Logo

SG16

Advanced search

Subject: Re: [SG16-Unicode] [isocpp-lib-ext] Proposed design change to P1030 filesystem::path_view
From: Andrew Tomazos (andrewtomazos_at_[hidden])
Date: 2019-08-28 05:56:28


On Wed, Aug 28, 2019 at 8:16 PM Ville Voutilainen <
ville.voutilainen_at_[hidden]> wrote:

> On Wed, 28 Aug 2019 at 07:18, Andrew Tomazos via Lib-Ext
> <lib-ext_at_[hidden]> 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.



SG16 list run by sg16-owner@lists.isocpp.org