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 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Ada Successor Language Date: Fri, 29 Jun 2018 23:36:18 +0200 Organization: Aioe.org NNTP Server Message-ID: References: <5e86db65-84b9-4b5b-9aea-427a658b5ae7@googlegroups.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> <1fbec811-1c54-4d6f-a072-447a0c8c23a2@googlegroups.com> NNTP-Posting-Host: 3CrKQyqWAJZHy6zYVP/kUg.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 Content-Language: en-US X-Notice: Filtered by postfilter v. 0.8.3 Xref: reader02.eternal-september.org comp.lang.ada:53454 Date: 2018-06-29T23:36:18+02:00 List-Id: On 2018-06-29 21:46, Dan'l Miller wrote: > On Friday, June 29, 2018 at 12:39:59 PM UTC-5, Dmitry A. Kazakov wrote: >> On 2018-06-29 15:25, Dan'l Miller wrote: >>> 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). >> >> I said nothing about •dispatch•! All types in question are statically known! > > Dmitry, do you even read what you write? In what you just wrote 12 hours ago above, the “classic multiple •dispatch•”, the “does no[t] support •MD•” where MD = multiple •dispatch•, the “compiler would ask the programmer to •override• it” via the OO tag/vtable mechanism, and the “••Problem solved••” all directly mention multiple •dispatch• and how MD is directly related to the remedy to maldesigns in user-provided assignment operators in your direct reply to slicing via C++ assignment. You are confusing "multiple dispatch" as a property of an operation with [multiple] "dispatch" as an act of resolution of a call at run-time. The former in Ada terms means that an operation has multiple controlling arguments/results see RM 3.9.2 for the term "controlling". If C++ had both arguments and the result of "=" controlling then the problem were resolved, regardless run-time dispatch involved or not. Equivalently, if C++'s assignment "=" were in Ada terms a primitive operation of its type the problem were resolved. In Ada terms C++'s "=" should have been declared as: function "=" (Left : in out T; Right : T) return T; Since C++ has no MD, it is effectively declared, again in Ada terms, as: function "=" (Left : in out T; Right : T'Class) return T'Class; This is a ticking bomb since C++ does not distinguish T and T'Class. As the result, "=" is contravariant in the second argument and the result. So goes a big boom, because contravariance is *unsafe* upon type extension. [I am sorry explaining such trivial things] > Turing test and uncanny valley come to mind. > >>> In the situations where slicing occurs, it is due to the old backwards-compatibility-with-C functionality in C++. >> >> I care little of C++ design flaws. There are plenty and C++ is far >> beyond the point where anything could be done to fix it. I argued that >> this problem could never occur in Ada with its sane type system. >> >> The case constituting this bug in C++ is well present in Ada: >> >> type T is tagged null record; >> function F return T; >> >> type S is new T with record >> I : Integer; >> end record; > > That is clearly not analogous to the vicinity where C++'s slicing occurs. It clearly is. Inheriting F could lead to the situation when some fields of S were undefined, just like inheriting assignment does. > ••Hypothetically•• in (not-this-timeline's-)Ada the analogous situation would be in the vicinity of: [...] None of the situations you mentioned could ever lead to the problem. There is absolutely no way to have such a thing in a strongly typed language. Whatever issues C++ has these are because of its weak typing. P.S. Like with dispatch, you keep on confusing Ada subtyping with OO and/or LSP subtyping. These are different things sharing only the name. In no way Ada's subtyping can be exposed to a problem similar to C++. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de