On Mon, 26 Sept 2022 at 12:28, Sébastien Bini <sebastien.bini_at_[hidden]>
wrote:

> On Mon, Sep 26, 2022 at 12:31 PM Edward Catmur <ecatmur_at_[hidden]>
> wrote:
>
>> On Mon, 26 Sept 2022 at 10:36, Sébastien Bini <sebastien.bini_at_[hidden]>
>> wrote:
>>
>>> My bad, I meant no user-provided *relocation, move or copy*
>>> constructors.
>>>
>>
>> Sure. I'd be a bit concerned that this is too restrictive, though it
>> shouldn't be a problem for tuple types as far as I can tell, but they might
>> want to user-provide special member functions for logging? This should be
>> called out, though.
>>
>
> I wouldn't know otherwise how to have the guarantee that all subobjects
> are independent from one-another. I also wonder whether we should impose no
> user-provided default constructor.
>

I think it's one or the other; if access is checked then the code accessing
the private/protected base/member is taking responsibility for maintaining
any relevant invariants. So long as access checking is bulletproof I don't
think we need to worry too much about a class breaking its own invariants;
the union hack would always be a possibility. I'd remove that requirement
(no special member functions) and say that if you break invariants by
decomposing into private bases and members that's your own responsibility.

But I still don't see the danger. We no longer care about the class
>>> invariant as the instance of that class we are concerned about is destroyed
>>> by std::decompose (the invariants of a destroyed object no longer hold
>>> anyway). Each subobject returned by std::decompose may have its own
>>> invariants and those are not violated.
>>>
>>
>> The base class may not be intended to be used outside the context of
>> being a private base class, so it may not maintain its own invariants (it
>> relies on the derived class for those).
>>
>
> Hmm true, although that would be fairly limited by the non-user-provided
> relocation, move or copy constructor clause.
> Anyway, I am okay with having std::decompose check for the accessibility
> of the base classes beforehand.
>
>
>> Yes, but adding a keyword that could be already in use as an identifier
>>>> is fraught, and could become an obstacle. An alternative is to construct a
>>>> sequence of punctuation tokens that cannot currently appear in a program,
>>>> as was done for spaceship; with that in mind, you might propose something
>>>> like `<~< x`?
>>>>
>>>
>>> I also thought of `&< x` lately, which looks a bit like shell
>>> redirection. I am not thrilled by this, `reloc x` conveys more meaning and
>>> stands out more IMO.
>>>
>>> C++11 managed to do the migration of `auto` quite well, with compilers
>>> giving warnings beforehand. The same could happen with `reloc`. Migrating
>>> the codebase to a new version of the language always involves some work.
>>>
>>
>> `auto` was already a keyword, though.
>>
>> Migrating to C++11 caused some trouble I recall, mainly because we wanted
>>> to migrate from boost smart pointers to those of the STL.
>>>
>>> I quickly looked at:
>>>
>>> - my personal projects and those of Stormshield, `reloc` is never
>>> used at all.
>>> - llvm has less than a hundred hits where `reloc` is used outside
>>> comments and strings (counting uses, not variable declaration), and reloc
>>> is never used to name a type, only variables.They mostly come from the ELF
>>> module.
>>> - FreeBSD. It's mainly C but also has some contribs in C++. We could
>>> argue that if reloc is not seen in a C codebase, chances are it is not used
>>> that much as well in C++. It has a bit more than a hundred hits. They
>>> mostly come from llvm (FreeBSD has less than a dozen hits if we exclude
>>> llvm from the count, and they equally come from C and C++ contribs.)
>>>
>>> This is just a quick search, but it gives us a hint that reloc might not
>>> be used that often.
>>>
>>> Anyway, I think I am going to propose both alternatives, while pondering
>>> in favor of `reloc`.
>>>
>>
>> Yes, that matches my own research; `reloc` is mostly used as an
>> identifier in ELF code. So it might be possible to use it, but it would
>> still have some cost.
>>
>> It's still a problem if `reloc` is used as only as a variable identifer;
>> are `reloc (x)`, `reloc + a` ill-formed relocation expressions or are they
>> function call, arithmetic expressions? Is `reloc x.y` an ill-formed
>> relocation expression or an expression missing an operator? I don't think
>> having a token that means a keyword only when followed by an identifier is
>> likely to be accepted.
>>
>
> I am thinking of proposing the following two alternatives, while pondering
> in favor of `reloc`:
>
> - either use a series of symbols, such as `&<` or `<~<`. It does not
> clash with existing code but it has a rather cryptic meaning.
> - or use `reloc` as a *keyword* (so there is no ambiguity in the
> code). It may clash with existing code albeit only a very small proportion
> of it, and the fixes are simple. (I need to look for more code bases to
> back that up). Also it clearly conveys the intent and eases code reading.
>
> I guess this proposal will have several revisions. I reckon it should be
> okay to leave some alternatives open in the first revision, and to decide
> later based on feedback.
>

Yes, that's the best approach.