Date: Fri, 27 Feb 2026 15:06:43 +0000
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):
- Code verbosity reduction. Ampliate the language allowing custom defaults for const/mut and noexcept/except (include new keywords to express opposite specifiers).
- 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)
- 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.
I'd appreciate opinions, problems or strong no-go reasons, or otherwise positive views if any.
Best,
Marcos Mayorga
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):
- Code verbosity reduction. Ampliate the language allowing custom defaults for const/mut and noexcept/except (include new keywords to express opposite specifiers).
- 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)
- 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.
I'd appreciate opinions, problems or strong no-go reasons, or otherwise positive views if any.
Best,
Marcos Mayorga
Received on 2026-02-27 15:06:54
