> I would love to avoid ordering function declarations, forward declaration is something that the compiler could figure out for classes and functions in my opinion.

We had that behavior inherited from C a long time ago: use of a non declared name "x" would produce an implicit external declaration for an "int" object or a function without prototype returning an "int" depending on the kind of expression in which "x" appeared first. That behavior from C was never a good fit for C++ for multiple reasons (think of overloading, namespace/class scopes, etc) is now removed from both C and C++.

On March 20, 2025 5:37:18 a.m. EDT, Filip via Std-Proposals <std-proposals_at_[hidden]> wrote:
>The problem with header file is common now, they already have to check versions.
>I still think however that it wouldn’t be a big problem if we don’t force programmers to use it right away and not generate an error.
>
>Maybe instead of making it an error we would give the benefits to convince people to use the new syntax.
>1. I would love to avoid ordering function declarations, forward declaration is something that the compiler could figure out for classes and functions in my opinion.
>2. Maybe this could become a way to define a lambda or replace function pointers as arguments (being precise with type definition and avoiding templates)
>‘’’
>fn foo(int i, fn(float a, double d) -> int) -> int {…}
>‘’’
>
>I’m not making any compilers so I only understand that it would be easier to analyze the code if there are clear distinctions between structures.
>
>
>> Wiadomość napisana przez Marcin Jaczewski <marcinjaczewski86_at_[hidden]> w dniu 19 mar 2025, o godz. 22:09:
>>
>> śr., 19 mar 2025 o 10:22 Filip via Std-Proposals
>> <std-proposals_at_[hidden]> napisał(a):
>>>
>>> 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.
>>>
>>
>> Yes, consider the same header files that are used by two projects, and
>> only one project moves to the new standard.
>> Now you need to add `#ifdef` to handle both, you make this wrongly and
>> you break third unrelated projects that use hacked version of Clang.
>>
>> Now multiple hundred headers by a hundred projects and you will have
>> 10+ years Python2-3 transition where any file could be "easy" upgrade
>> from 2 to 3.
>>
>>> 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
>>>
>>> --
>>> 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