The key word to google here is "epochs." See previous discussions around
them, on Reddit and elsewhere.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1881r0.html
https://vittorioromeo.info/index/blog/fixing_cpp_with_epochs.html

I haven't been following very closely, but my impression is that most of
the interesting things you would want to be able to do with epochs, are
still very hard and/or impossible to specify. Maybe if you limit it to just
properties that already exist in C++17 and you're just changing the
defaults, okay; but you couldn't do anything really interesting like
autogenerate `operator<=>` by default, or change the ABI of unique_ptr, or
change the rules of ADL or default function arguments, or anything big like
that.

–Arthur


On Tue, Jan 19, 2021 at 10:48 AM Paul Fee via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> Hello Vinícius,
>
> I've often thought it would be preferable to have variables
> immutable/const/read-only by default, following the principle of least
> privilege. That would make C++ stricter and perhaps more secure by
> default.
>
> Backwards compatibility however means the default of
> mutable/non-const/read-write can't be changed. Your suggestion of
> scope wide specifiers has appeal. I'd like to see it explored
> further.
>
> Thanks,
> Paul
>
> On Tue, Jan 19, 2021 at 2:36 PM Vinícius Costa via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> >
> > Hi!
> >
> > I'd like to propose a new attribute to change the default specifiers and
> qualifiers in a given scope.
> >
> > Often there's a lot of boilerplate code involved because the default
> specifiers and qualifiers are not the "correct" ones (stress on the
> quotation marks).
> > So we need to explicitly make variables const, functions const, noexcept
> or final, etc.
> >
> > It would be a lot simpler to have a way to switch the default specifiers
> and qualifiers, making them more permissive or stricter.
> >
> > The idea is to create an attribute that would apply to a scope. With
> that, we won't mess with back-compatibility and it would allow an easy
> migration towards the new standard.
> > Furthermore, it would help to enforce some good practices like
> const-correctness.
> >
> > For example, the following two codes will be the same.
> >
> > namespace example [[strict]] {
> > class Foo : public Bar
> > {
> > void do_it(double *ptr) override
> > {
> > int x = /* some initialization code here*/
> > /* more code here */
> > }
> > };
> > }
> >
> > namespace example {
> > class Foo final : public Bar
> > {
> > void do_it(double * __restrict ptr) const noexcept override final
> > {
> > const int x = /* some initialization code here*/
> > /* more code here */
> > }
> > };
> > }
> > --
> > Std-Proposals mailing list
> > Std-Proposals_at_[hidden]
> > https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>