From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 2002:a24:640e:: with SMTP id t14-v6mr787410itc.0.1530278705055; Fri, 29 Jun 2018 06:25:05 -0700 (PDT) X-Received: by 2002:aca:c744:: with SMTP id x65-v6mr712545oif.2.1530278704927; Fri, 29 Jun 2018 06:25:04 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!news.linkpendium.com!news.linkpendium.com!news.snarked.org!border2.nntp.dca1.giganews.com!nntp.giganews.com!u78-v6no483776itb.0!news-out.google.com!p13-v6ni775itf.0!nntp.google.com!d7-v6no492447itj.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Fri, 29 Jun 2018 06:25:04 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=47.185.195.62; posting-account=zwxLlwoAAAChLBU7oraRzNDnqQYkYbpo NNTP-Posting-Host: 47.185.195.62 References: <5e86db65-84b9-4b5b-9aea-427a658b5ae7@googlegroups.com> <87fu1izfgs.fsf@nightsong.com> <878t75nwad.fsf@adaheads.home> <15b6f89f-997b-45ac-86b4-2e614bb624c2@googlegroups.com> <28a46046-e7eb-4306-bc39-72bc751831ae@googlegroups.com> <400ba7f8-6875-4ba8-99ee-c105180d5d8b@googlegroups.com> <87tvpm1e2q.fsf@nightsong.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <1fbec811-1c54-4d6f-a072-447a0c8c23a2@googlegroups.com> Subject: Re: Ada Successor Language From: "Dan'l Miller" Injection-Date: Fri, 29 Jun 2018 13:25:05 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader02.eternal-september.org comp.lang.ada:53430 Date: 2018-06-29T06:25:04-07:00 List-Id: 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 > >=20 > > Are you talking about this? > >=20 > > https://en.wikipedia.org/wiki/Object_slicing > >=20 > > Does Ada somehow escape from it now? >=20 > Sure, there is no way to reconstruct that in Ada. >=20 > > It does sound bad. >=20 > Only due to C++ design fault. Assignment is a classic multiple dispatch= =20 > operation (a multi-method). C++ per design does no support MD. Here you g= o. >=20 > With MD it is no more an issue. Let T and S be two types T <: S. The=20 > assignment operation of mixed arguments and result >=20 > ":=3D" : S x T -> S >=20 > could not be safely inherited by S from T's: >=20 > ":=3D" : T x T -> T >=20 > Therefore the compiler would ask the programmer to override it (or=20 > redesign). Problem solved. Dmitry, you make it sound as though multiple dispatch would solve slicing i= n C++ (which has no dispatch whatsoever). In the situations where slicing = occurs, it is due to the old backwards-compatibility-with-C functionality i= n C++. No vtable, pointer-to-vtable, no dispatching required to utilized o= r 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 (w= hole records in Ada-speak), not on addresses per se: pointers alone, l-valu= e references alone, r-value references alone or 3.2) when at least one member-function (subprogram in Ada-speak) of the =E2= =80=98same name=E2=80=99 is present in the base class and derived class tha= t was not virtual (Ada83 subtype =E2=80=98inheritance=E2=80=99 in Ada-speak= , due to being untagged inheritance). In C++, base-struct's and derived-st= ruct's destructors=E2=80=94either human authored or compiler generated=E2= =80=94have the =E2=80=98same name=E2=80=99 for our purposes here, despite h= aving 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 wor= king 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 goa= l (e.g., assignment, shallow copy, pass-by-value, return-by-value, and so f= orth) 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 recor= d by working with Ada83-era subtype inheritance that by its nature is untag= ged. 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 seman= tics. Only by a dozen foresightful wisdoms & preclusions & carve-outs in j= ust the right places of the _LRM_ does Ada not have much the same problem.