Date: Wed, 19 Mar 2025 10:42:34 +0000
On Wed, 19 Mar 2025 at 01:56, Fady al Dhaim via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> *2. Why This Won’t Break Existing Code*
>
> This proposal is *backward-compatible* because:
>
> -
>
> auto is *already optional* in normal return types:
>
> int func();
>
> -
>
> This change is *purely syntactic*—it does not affect semantics.
> -
>
> Existing code using auto remains *fully valid*.
> auto func() -> int; // Remains valid
> auto func() -> decltype(some_expression); // Also valid
>
> Thus, this proposal only *removes an unnecessary restriction* without
> introducing breaking changes.
>
It's not an unnecessary restriction though.
There was lots of discussion about the new function declarator syntax when
it was being introduced.
See for example
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1978.pdf
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2337.pdf
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2954.html (and
the many references in its introduction).
std-proposals_at_[hidden]> wrote:
> *2. Why This Won’t Break Existing Code*
>
> This proposal is *backward-compatible* because:
>
> -
>
> auto is *already optional* in normal return types:
>
> int func();
>
> -
>
> This change is *purely syntactic*—it does not affect semantics.
> -
>
> Existing code using auto remains *fully valid*.
> auto func() -> int; // Remains valid
> auto func() -> decltype(some_expression); // Also valid
>
> Thus, this proposal only *removes an unnecessary restriction* without
> introducing breaking changes.
>
It's not an unnecessary restriction though.
There was lots of discussion about the new function declarator syntax when
it was being introduced.
See for example
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1978.pdf
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2337.pdf
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2954.html (and
the many references in its introduction).
Received on 2025-03-19 10:42:50