Hi Frederick,

Large changes to C++ need comparatively large rationale.

Changing the type system in major ways is certainly a large change,
in my view.

Part of the rationale why a core language mechanism is needed
is to show what a comparable library-only approach would look like.
Maybe the library approach is awkward to use, maybe it doesn't
deliver all the features you want, but at least it needs to be
discussed in the paper, with examples.

Also, changing the type system might impact the latitude given
to type-based alias analysis in compilers, which is important
for optimizers. Any changes in that area need to be discussed
in the paper.

The C++ core language is already a fairly complex beast, so I'd
like to understand why we need a particular extension, and what
part of the user community is likely to benefit. In contrast,
a library approach is, in general, far less intrusive.

Jens


On 25/02/2023 12.48, Frederick Virchanza Gotham via Std-Proposals wrote:
> 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'.