Re: The Case for Rust (in any system)

Jan Knepper <jan@digitaldaemon.com> writes:

> On 9/9/24 10:05, David Chisnall wrote:
>
>  On 9 Sep 2024, at 14:32, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
>
>  David Chisnall writes:
>
>  On 9 Sep 2024, at 12:24, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
>
>  What might that subset be?
>
>  Initially it will be "better C compiler", but then we will gradually
>  allow more and more of C++ to be used.
>
>  In my experience, the worst C++ code is written by people thinking in C. 
>  The second worst is written by people thinking in Java (or Smalltalk).
>
>  I dont disagree :-)
>
>  But it's either a gradual approach or "never" because a rewrite in toto wont happen.
>
>  I agree, incremental change is always better.  I just don’t want to encourage anyone to write C++ that looks like C,
>  because that’s going to combine the frustrations people have with C and C++.  A gradual approach needs a simple step
>  1, but it also needs a step 2, and then a step 3, and so on.  
>
> Second.

I've mentioned MISRA C++:2023 already, but would like to elaborate on my
idea behind it. It forms a subset of ISO/IEC 14882:2017 (C++17) by
introducing guidelines which are "directives" or "rules". At the same
time each guideline falls into one of the "mandatory", "required" or
"advisory" category.

For example, there's a rule 13.1.1 which prohibits classes to be
inherited virtually, but it's in the "advisory" category at the same
time. Rule 13.3.1 states that user-declared member functions shall use
the virtual, override and final specifiers appropriately.

It should be less time consuming to analyze existing guidelines prepared
by MISRA C++:2023 and form steps simple enough to be adopted by the
project, I think.

Regards,
Dmitry

-- 
https://wiki.freebsd.org/DmitrySalychev