On 2026-02-28 at 08:15, Simon Schröder via Std-Proposals wrote:
>
>
>> On Feb 27, 2026, at 4:07 PM, mm-studios via Std-Proposals <std-
>> proposals_at_[hidden]> 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.

There is a problem in using context sensitive keywords, when that
keyword is used to establish the context! It works for 'override'
because that is used in a place (far at the end of a context) where
nothing else is allowed.

Otherwise there will be problems with things like a potential

mut auto x = 1;

where 'mut' can already be a concept.

Also, the more "special identifiers" (non-keywords) we add, the more
difficult it will be to parse the code. We have already seen code with
no keywords at all in PL/I. That allows for scary things like

if if = then then then = else else else = if;

The first 'if' starts a conditional statement, the second 'if' is a user
defined variable. We surely don't that to happen in C++.