On Fri, Feb 24, 2023, Ville Voutilainen wrote:
>
> This paper should be burned, not sent to WG21 to spend time on.


I admire your fervour; it's important to have passion in debate.


> Okay then. The production of this paper is ignoring feedback,
> especially including examples where the goal of this facility can just
> be achieved with the existing language,


I did read the email you sent on Thu, Feb 23, 2:08 PM (UTC+0) however
since you didn't post any code, and since my imagination didn't
spontaneously compose the code you were describing, I don't yet have a
'pure library' solution to the problem I posed.
The burden of proof rests with the person making the assertion. *You*
are the one saying that what I want can be achieved without editing
the core language. Don't rely on my imagination, give me the proof. If
you're not bothered writing code then don't expect me to be bothered
wrangling your hypothesis.
You later posted some code that does something similar but not exactly
the same, and I'll respond to that below. . .


> 1) this isn't an interface, this is a downcast target, that's not what
> 'interface' means.


64 popular English dictionaries have a definition for 'interface', you
can see them all here:

    https://www.onelook.com/?w=interface&ls=a

But since I didn't write any of those dictionaries and therefore don't
take responsibility for them, I'll write my own understanding of the
word 'interface' from the perspective of a person who was born in the
1980's in Ireland, and who's been programming since the 90's, in the
context that I mean it:
"An interface allows something to be a black box, you don't need to
know about or understand the black box's internal working, you just
need to be familiar with the black box's interface. The definition of
the interface is a list of well-defined rules for how to interact with
the black box."

I don't need to know how a binary_sempahore works internally -- and
99% of people who use it don't -- I only need to know how to use it,
that is to say: I only need to be familiar with its interface
(acquire, release) and what behaviour to expect.


> 2) interface is a keyword-lookalike macro extension in some sizeable
> C++ codebases in use today


That hadn't crossed my mind. If it turns out that some header files
around the world have "#define interface" in them then I might use
another word or symbol.


> 3) there's nothing 'new' in what it does


I don't know if you're alluding to my use of the 'new' keyword, or if
you're saying that the feature I'm proposing doesn't do anything new.
Anyway, my proposal allows you to use an object as though it had a
different interface -- that would be something new for C++.


> 4) it's not an alias, so 'using' is just wrong


I'm extending the C++ language, and extending what some keywords can
do. But anyway right now the syntax isn't of great importance.


> 5) delete clear; already has meaning elsewhere, and it's just
> nonsensical to write a deleted declaration that way,
> we already have a syntax for deleted declarations.


Yeah you're right here, I could have went with:

    void clear(void) = delete;

but I wanted to have a way to delete any member irrespective of
whether its a member object or a member function (and irrespective of
the member function's signature). But maybe the exactness of your
suggestion is better here.


> If we want a negation of a using-declaration, which would selectively
> removes one declaration, that should be proposed as a language feature
> of its own, but given that there's hardly any convincing rationale, I don't
> think that's a good use of our time.


Thank you for the inspiration here, I might write a separate paper
entitled "!using".


- - - - - - Moving on to next author - - - - - - - -


Thiago Macieira wrote:
> If 12 people take 10 minutes to review what you're writing, understand it, and
> maybe write a thoughtful reply, that's 2 hours of cumulative time.


Have you seen the movie 'Arrival'? It's about aliens who experience
time differently to us. They don't have past, present and future, but
rather they experience everything all at once. Thiago, you seem to
have a different perception of time to the average humanoid. I mean if
12 people each take 10 minutes to do something in parallel, then the
entire activity takes 10 minutes. You've somehow turned that into 2
hours -- you might have the plot for a good SciFi movie there, maybe
call it "Parallels In Series".


- - - - - - Moving on to next author - - - - - - - -


Jason McKesson wrote:
> It makes a mockery of the type system and even if this were a
> well-formed proposal, it should be abandoned on that basis.


And what about a 'union'? Do think a union has the utmost reverence
for the type system?
Since /every/ C++ compiler can already do what I'm proposing, I'm
really just asking for the Standard to explicitly allow something that
every compiler is already doing anyway.


> The text of this proposal treats an "interface" as a thing that is a
> type. It is not presented as a new kind of entity; it is a type. This
> is why you have to explicitly forbid things like virtual functions,
> member variables and the like, because the proposal treats an
> "interface" as just a new way to write a type. The "interface"
> inherits from a type and therefore inherits everything in the "base"
> type.
>
> That is not acceptable.


Yes, every interface is a type, in fact you can even typedef an
interface, for example:

    interface lockable_binary_semaphore : std::binary_semaphore { /*
Stuff goes here */ };

    typedef lockable_binary_semaphore monkey;

You have closed out your paragraph with the one-liner "That is not
acceptable" without saying why. As I tole Ville above, I'd prefer you
didn't rely on my imagination.


> The reason why "casting" a class to a derived class that it definitely
> is not is UB is because it breaks the strict aliasing rule. There is
> no derived class object instance there, so pretending that there is
> one is nonsense. That this "works" on various compilers is completely
> irrelevant to this fact. It is UB behavior because it makes no sense
> in terms of the object model.


There's a page in my paper dedicated to aliasing but maybe you didn't
read it. Here you're talking about UB but my paper explicitly says
that the behaviour is well-defined.


> If you manufacture the "interface" type around some existing object,
> what is to stop someone from manufacturing a *different* interface
> type around that same object? So... which is it? An object cannot have
> two types; that is again antithetical to how the C++ object model
> works.


You cast it to a reference. Let's say the original class was called
'Monkey', and let's say that there are two interfaces called "Frog"
and "Cheetah" which are both based on Monkey. Well, you can do the
following:

    Monkey obj;

    Frog &frog = obj;
    Cheetah &cheetah = obj;

    Frog *pf = &obj;
    Cheetah *pc = &obj;

You say that it's antithetical to the C++ object model but my paper
explains how it all works. /Any/ change to /anything/ will also be
antithetical at first glance.


> Trying to hack the type system for this is just not acceptable as an approach.


Your use of the word 'hack' here is where I would use the word 'change'.