Re: [lmi] Detecting whether move semantics actually take place

[Greg Chicares]

On 8/3/22 12:33, Vadim Zeitlin wrote:
> On Tue, 2 Aug 2022 00:33:55 +0000 Greg Chicares <gchicares@sbcglobal.net> 
> wrote:
> 
> GC> On 7/23/22 15:41, Vadim Zeitlin wrote:
> GC> [...]
> GC> >  First, and trivially, you should sprinkle magic constexpr dust all over
> GC> > your code
> GC> 
> GC> Done, in the second-oldest change here:
> GC> 
> GC>   origin/odd/move_semantics
> GC> 4c41e5790 Expunge a semiotic nightmare
> GC> cc46b95a1 Use 'concept' syntax
> GC> f09746b48 Expand commentary
> GC> 03e061cf6 Replace run-time with compile-time tests
> GC> 2fbb26c9f Improve documentation
> 
>  FWIW I've looked at these commits and didn't have anything to say about
> them (except for remaining completely oblivious to "a Sable, c Bible"
> remark in a comment, but I don't think it's materially important here).

internationalization
 123456789012345678   eighteen characters to omit
i18n                  customary abbreviation

Having grown weary of repeatedly typing "assignable" and "constructible",
I wondered whether I should apply that abbreviation pattern:

assignable
 12345
a5able    abbreviation
aSable    near-homograph

constructible
 12345678
c8ible    abbreviation
cBible    near-homograph

The abbreviations become indistinguishable from their near-homographs as
one moves farther and farther away from the screen. For me, that distance
is less than one meter, even with a 16-point font at 192 DPI.

That's only one conclusive reason for rejecting these abbreviations.
Another is that they're incomprehensibly zany.

> GC> Right now I'm just staring at:
> GC> 
> GC> struct can_copy
> GC> {
> GC>    can_copy() = default;
> GC>    can_copy(can_copy const&) = default;
> GC>    can_copy(can_copy&&)      = delete;
> GC>    can_copy& operator= (can_copy const&) = default;
> GC>    can_copy& operator= (can_copy&&)      = delete;
> GC> };
> GC> 
> GC> can_copy a {};
> GC> can_copy b {a}; // Looks copy-constructible to me.
> GC> can_copy c = b; // And copy-assignable, too.
> GC> 
> GC> static_assert(std::copyable<can_copy>);
> 
>  You don't mention it, but this fails too, doesn't it?

Yes, certainly. It's "copyable" in the sense that I can copy it.
However, it is not   "copyable()".

> GC>      copy_constructible
> GC>   is_copy_constructible
> GC> having different meanings.
[...]
> the hope is/was for copy_constructible() to be more
> useful in practice, but is_copy_constructible() is not useless, or at least
> not harmful, enough to be deprecated neither. At least this is how I would
> justify it if I had to.

As natural languages evolve, the new displaces the old.
With programming languages, the old is retained. As the
Carbon manifesto points out, C++'s technical debt just
keeps growing, and someday a revolution must come.