Re: Ada Successor Language

["Dan'l Miller" <optikos@verizon.net>]

On Friday, June 29, 2018 at 2:20:40 AM UTC-5, Dmitry A. Kazakov wrote:
> On 2018-06-29 05:11, Paul Rubin wrote:
> > "Dan'l Miller" writes:
> >> bad idea that threatens to bring C++ slicing to Ada
> > 
> > Are you talking about this?
> > 
> >     https://en.wikipedia.org/wiki/Object_slicing
> > 
> > Does Ada somehow escape from it now?
> 
> Sure, there is no way to reconstruct that in Ada.
> 
> > It does sound bad.
> 
> Only due to C++ design fault. Assignment is a classic multiple dispatch 
> operation (a multi-method). C++ per design does no support MD. Here you go.
> 
> With MD it is no more an issue. Let T and S be two types T <: S. The 
> assignment operation of mixed arguments and result
> 
>     ":=" : S x T -> S
> 
> could not be safely inherited by S from T's:
> 
>     ":=" : T x T -> T
> 
> Therefore the compiler would ask the programmer to override it (or 
> redesign). Problem solved.

Dmitry, you make it sound as though multiple dispatch would solve slicing in C++ (which has no dispatch whatsoever).  In the situations where slicing occurs, it is due to the old backwards-compatibility-with-C functionality in C++.  No vtable, pointer-to-vtable, no dispatching required to utilized or even to be present at all.  Slicing occurs at the intersection of:
1) inheritance (a.k.a. record extension in Ada-speak)
2) C semantics;
3) either:
3.1) when, regarding the base-struct, operating on whole structs/classes (whole records in Ada-speak), not on addresses per se: pointers alone, l-value references alone, r-value references alone
or
3.2) when at least one member-function (subprogram in Ada-speak) of the ‘same name’ is present in the base class and derived class that was not virtual (Ada83 subtype ‘inheritance’ in Ada-speak, due to being untagged inheritance).  In C++, base-struct's and derived-struct's destructors—either human authored or compiler generated—have the ‘same name’ for our purposes here, despite having different names of types; focus on the tilde ~ and the AST more than the type-name of the struct.

At the intersection of those 3 then the C++ compiler deduces that it is working in C mode instead of OO mode and abuses the strong type that it thinks that is in play (i.e., the base struct) and accomplishes the requested goal (e.g., assignment, shallow copy, pass-by-value, return-by-value, and so forth) thinking in C-semantics only of the base-struct, not in OO-semantics of bringing along the derived-struct's extension too.

Even when a vtable is present, you can convince a C++ compiler to ignore it by working in C semantics instead.  The hypothetical analogue in Ada would be to somehow convince an Ada compiler to ignore an Ada95-era tagged record by working with Ada83-era subtype inheritance that by its nature is untagged.  At some crude level, Ada has the Ada83 semantics and the Ada95-onward semantics analogous to C++ having the C-era semantics and the OO-era semantics.  Only by a dozen foresightful wisdoms & preclusions & carve-outs in just the right places of the _LRM_ does Ada not have much the same problem.