From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.5-pre1 Path: eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: John McCabe Newsgroups: comp.lang.ada Subject: Re: Adacore Blog - Going Beyond Ada 2022 Date: Mon, 14 Jun 2021 10:35:03 -0000 (UTC) Organization: A noiseless patient Spider Message-ID: References: <87v96n2e2h.fsf@nightsong.com> <54c3041a-b68f-4719-88bc-d2a1587a2d2cn@googlegroups.com> <12a77501-1187-4f83-a1ad-8bf7e95b1040n@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Injection-Date: Mon, 14 Jun 2021 10:35:03 -0000 (UTC) Injection-Info: reader02.eternal-september.org; posting-host="0e3b73105d446a5bfdc0e0a76ad73cc4"; logging-data="6135"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19zfnJIeEyVSSsyJYnL/fR0tga1Yfv3pog=" User-Agent: Pan/0.147 (Sweet Solitude; 97d1711 github.com/GNOME/pan.git) Cancel-Lock: sha1:+5TVfT9WRyjZfukDcqnwW4y8hek= Xref: reader02.eternal-september.org comp.lang.ada:62225 List-Id: On Sun, 13 Jun 2021 13:29:44 -0700, Andreas ZEURCHER wrote: > C++ for example rarely if ever has cases where some core-language > feature appeared in GCC or Clang prior to having at least one N-series > proposal submitted to the ISO14889 committee (and indeed, not only > submitted, but achieving some degree of partial consensus, at least > factionally). For example, Clang has automated reference counting (ARC) > only in Objective-C-based modes of operation (including in only certain > Objective-C-centric situations of Objective-C++), not in C++ proper. > Likewise with Microsoft's C++/CLI and C++/CX keeping evolution to the > core language separate from the committee-draft-proposal-centric main > language—a few nonstandard pragma-esque attributes here & there > notwithstanding. FWIW, though, the C++ committee appear to think it's acceptable to strangle the specification of certain features based on whether or not it makes it hard for a specific compiler to implement. A few weeks ago I had reason to look into the justification for something in C++ that appeared, to me, to be stupid and illogical, and the reasoning was because "clang does something this way and, if we took the sensible approach for this feature, it would mean clang would have to massively change". So now the C++ world is saddled with a specification that's compromised by specific implementations. I've been trying to find the discussion I had about this with some of my colleagues at work; if I do, I'll let you know what it is! However, this is, basically, a potential risk with the AdaCore RFC approach; if they forward the feature to the ARG and the ARG comes back with "well, nice, but it would be better if it did this", and AdaCore say "but that would be too hard for us now", then what happens?