C++ Logo

sg16

Advanced search

Re: [SG16-Unicode] [isocpp-lib-ext] Proposed design change to P1030 filesystem::path_view

From: Andrew Tomazos <andrewtomazos_at_[hidden]>
Date: Wed, 28 Aug 2019 20:56:28 +1000
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.

Received on 2019-08-28 12:56:41