On Feb 27, 2026, at 4:07 PM, mm-studios via Std-Proposals <std-proposals@lists.isocpp.org> wrote:


Hi C++ enthusiasts,
This is my first message to std proposals.
I wanted to share a few different ideas expressed as 1liners I could work further, in order to find reasons for pursuing them (or not) as formal proposals. These ideas are (succinct):

  1. Code verbosity reduction. Ampliate the language allowing custom defaults for const/mut and noexcept/except (include new keywords to express opposite specifiers).
I believe that this problem could be solved outside the language with an IDE. The IDE could show code differently than what is saved inside the file. E.g. the IDE could show ‘mut’ in front of all mutable variables and when you don’t use the mut “keyword” when declaring a variable it will be const. Same with noexcept. However, the problem with the opposite of noexcept didn’t work: originally (C++98) you were supposed to write a throws specification and nobody did that. Maybe the noexcept by default could be handled by an exception-free profile.

There is a small disadvantage for the IDE-based solution: we would need additional keywords. If those are not specified in the language itself, it will be a little harder to enforce no variables with the name of these “keywords” (especially in library code). On the other hand, these “keywords” could be context specific. Or we might reserve these keywords in the language specification without using them in the standard.
  1. Code verbosity reduction. Eliminate auto keyword or making it optional. Are there strong reasons to keep typing auto when compilers might deduce its presence just because it's missing (positional abscense)
The history of computer science shows that this is a bad idea! Rockets have exploded because of automatically declared variables. This was (and I believe still is) the default in Fortran. (However, in Fortran the first letter of the variable defines the type of the variable as either integer or floating point.) The problem that would arise is that a typo would accidentally introduce a new variable. I consider the compiler my best friend in pointing out typos as errors. Because of compiler errors I also only rarely use ‘auto’, but will specify the type of the variable type explicitly. Then the compiler will notify me when I don’t get the type that I expected. I prefer to tell the compiler everything I assume and let the compiler correct me if I’m wrong.
  1. Abstraction. Elevate abstraction on pointer dereference. Does it really matter if we use "." (dot) or "->" (arrow) to access internal structure?. I can foresee complexities with smart pointers, where both methods are used to access 2 different interfaces (for for smart_ptr object, arrow for accessing the dereferenced underlying object. But it might be a subject to brainstorm it further.
In plain C this would actually work (and also with raw pointers in C++). There is an interesting read about why we have the two versions in the first place: https://retrocomputing.stackexchange.com/questions/10812/why-did-c-use-the-arrow-operator-instead-of-reusing-the-dot-operator/10858#10858
The shortcuts allowed initially, are not valid C anymore. So, there is no reason for two different operators in C anymore. 

Just as others have noticed, it gets complicated with operator overloading (smart pointers and iterators). There has also been a proposal for overloading operator. (by Herb Sutter?) which discusses some of the same problems. Maybe some of these solutions could be backported to your suggestion (like using .. instead of just . in certain cases to disambiguate). If we can get operator. into the standard (and force it to have the same behavior as operator->), we could merge the meaning of operator. and operator-> by allowing a . everywhere.

I'd appreciate opinions, problems or strong no-go reasons, or otherwise positive views if any.

I’m strongly against number 2. All modern (comparable) languages use a keyword to introduce a new variable (var, mut, …). With C++ this just happens to be auto (for historical reasons, as this keyword was available).

Best,
Marcos Mayorga

--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals