1) Look up previous discussions surrounding epochs.
2) Explore it more. Explain where you think it can be removed.
3) You've already pointed out a problem: how would you then
distinguish invoking a member function on a unique_ptr vs a member
function on what the unique_ptr points at? (Including cases where
both levels has the same function signature, like "T * release()")

I think these are all currently too early to come to the proposals
mailing list. There should be some investigation on your side as to
the implications of what you've suggested. Show that you've
considered what's the impact on existing code. For example, on your
second item: what's the result of "for ( i = 0; i < 10; ++i) {}" ?
Does that depend on i being earlier declared, or this is an instance
of the "eliminated auto keyword" and what I meant was to declare a new
"int i" for the scope of the for loop, intentionally shadowing a
previously declared i?

"Code verbosity reduction" is not a magic phrase. I know many folk
who feel that being explicit about everything is the correct way to go
(things like "never use auto").

On Fri, Feb 27, 2026 at 7:06 AM 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):
>
> 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
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals