czw., 20 mar 2025 o 10:37 Filip <fph2137_at_[hidden]> napisał(a):
>
> 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.
>

But you force even more checks in places where previously you did not need any.
All C++ authors need to check if they libraries if they will compile
correctly, if not they need to add checks.
What if there is no author around any more or projects use an older
version of the library?
Who will update that?

> 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.
>

You only add new corner cases to language that is rich in that, see
"most vexing parse".


Again please see and analyze the Python case, how "small" breaking
changes take 10y to adapt in a big world.
(Another case like this is C++11 `std::string` in GCC)
I would argue that in the case of C++ it would be 2 or even more times longer.

>
> > 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