Huge resources to change the name from fn to fun or func or even just Fn?
Maybe it could be rolled out in 2 iterations, firstly restrict the use of keyword and warn the user that in the next standard it will be a keyword introducing a function and then just change it.

To make it more appealing for change maybe this style could also resolve the issue of declaring a function? Is it impossible right now for the compiler to assume that the function of a given signature should exist by the end of compilation and just wait for it?

I’m not advocating complete change and departure from c style functions, but it could be a compiler flag or something that could warn us about the mixed used of different declarations styles.

To be honest I think that there’s a lot of organizations that still use c++11 or 14. They don’t want to update it “because it works already”.
But we can’t really measure that.

> Wiadomość napisana przez Sebastian Wittmeier via Std-Proposals <std-proposals_at_[hidden]> w dniu 19 mar 2025, o godz. 09:58:
>
> 
> No, it is not easy.
>
> An important corner stone of C/C++ is compatibility.
>
>
>
> Changes of code or checks, even if it can be automatically done, cost huge resources. Many organizations would delay or stop to update to newer C++ revisions.
>
>
>
> There are companies with hundreds of millions of lines of code.
>
> Even with tooling support, your suggestion easily could cost a million or more for each of them.
>
>
>
> And this only, if you now support old and new syntax, which makes it even more difficult to compile.
>
>
>
> Allowing function definitions and declarations _only_ with fn keyword would be a dead-end and language split. 99.9% would not follow such a new standard. Some just for the reason because they know that this variant would have no future.
>
>
>
>
>
>
> -----Ursprüngliche Nachricht-----
> Von: Filip <fph2137_at_[hidden]>
> Gesendet: Mi 19.03.2025 09:37
> Betreff: Re: [std-proposals] Proposal: Making The auto Keyword Optional in Trailing Return Types
> An: std-proposals_at_[hidden];
> CC: Sebastian Wittmeier <wittmeier_at_[hidden]>; std-proposals_at_[hidden];
> Changing the name of that identifier is easy so maybe it’s possible to warn programmers about it and just introduce it if it’s going to help us.
>
> A bit of uncomfortable phase, sure, but maybe it’s better that way for everyone.
>
> Cheers, Filip
>
>>> Wiadomość napisana przez Sebastian Wittmeier via Std-Proposals <std-proposals_at_[hidden]> w dniu 19 mar 2025, o godz. 09:26:
>>>
>> 
>> It would, but with its own cost.
>>
>> All current programs using fn as an identifier would malfunction.
>>
>>
>>
>> There are far less common and longer potential keywords, which have been rejected for that reason.
>>
>>
>> -----Ursprüngliche Nachricht-----
>> Von: Filip <fph2137_at_[hidden]>
>> Gesendet: Mi 19.03.2025 09:22
>> Betreff: Re: [std-proposals] Proposal: Making The auto Keyword Optional in Trailing Return Types
>> An: std-proposals_at_[hidden];
>> CC: Sebastian Wittmeier <wittmeier_at_[hidden]>; std-proposals_at_[hidden];
>> Just a thought but wouldn’t introducing keyword ‘fn’
>> Simplify compilation?
>> It would be easier for the compiler to know if what is being written is specifically a function or a variable.
>>
>> Cheers, Filip
>>
>>>> Wiadomość napisana przez Sebastian Wittmeier via Std-Proposals <std-proposals_at_[hidden]> w dniu 19 mar 2025, o godz. 07:02:
>>>>
>>> 
>>> See
>>>
>>> https://www.reddit.com/r/cpp/comments/cn863t/why_is_auto_required_when_using_a_trailing_return/?rdt=44901
>>>
>>> with
>>>
>>> https://godbolt.org/z/2jXUG9
>>>
>>>
>>> -----Ursprüngliche Nachricht-----
>>> Von: Fady al Dhaim via Std-Proposals <std-proposals_at_[hidden]>
>>> Gesendet: Mi 19.03.2025 02:57
>>> Betreff: [std-proposals] Proposal: Making The auto Keyword Optional in Trailing Return Types
>>> An: std-proposals_at_[hidden];
>>> CC: Fady al Dhaim <fadyaldhaim_at_[hidden]>;
>>> Hello,
>>>
>>> I’d like to propose a small but meaningful change to C++: making auto optional in trailing return types.
>>>
>>> 1. Motivation
>>> Currently, auto is required in functions that use trailing return types:
>>>
>>> auto func() -> int; // Required
>>> However, this requirement is redundant and misleading because:
>>>
>>> The return type is explicitly specified (int), so auto adds no value.
>>> auto implies type deduction, but no deduction is happening here.
>>> A more natural syntax would allow:
>>>
>>> func() -> int; // More intuitive Right?
>>
>> Not only does this improve readability and consistency with standard function declarations, but it also aligns well with Software Engineering Structural Diagrams, such as UML Class Diagrams and Object Diagrams.
>>
>>
>>
>> In UML Class Diagrams, method return types are typically represented after the function name, similar to how trailing return types work in C++. Allowing func() -> int; without auto makes the C++ syntax closer to UML representations, enhancing clarity and traceability between a codebase and its corresponding UML models.
>>
>> 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.
>>
>> 3. Proposed Change
>> Modify the C++ grammar so that functions using trailing return types no longer require auto.
>> This would allow:
>>
>> Current (C++ Standard Today)
>> auto func() -> int; // Required
>> Proposed (New Syntax Allowance)
>> func() -> int; // Allowed
>> This makes the syntax more consistent with regular function declarations.
>>
>> 4. Next Steps
>> Would this be a reasonable proposal for a future C++ standard update?
>> I’d love to hear your thoughts and suggestions on how this could be refined further.
>>
>> Best regards,
>> Fady al Dhaim
>>
>> -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals