On Mon, Sep 26, 2022 at 12:31 PM Edward Catmur <ecatmur@googlemail.com> wrote:

On Mon, 26 Sept 2022 at 10:36, Sébastien Bini <sebastien.bini@gmail.com> 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.