Re: Adacore Blog - Going Beyond Ada 2022

[John McCabe <john@nospam.mccabe.org.uk>]

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?