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.


> 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.