[SUGGESTION] Make free functions illegal

[ivo-doko]

Off-topic introduction

I would like to begin with a bit of an apology. My input in this space so far has been exclusively negative (primarily expressing trepidation). Given that the reason I'm here at all is fascination and admiration, I don't want that to be the case and would like my input to be more productive. With that out of the way...

---

Inspired by issues discussed in #1334, particularly regarding:

It is not available right now for free functions with deduced return types. It's too early to say that it's not doable at all for free functions with deduced return types. Even if that were to be true, that just means that free functions with deduced return types are not order-independent. Functions with fixed return types still are. It also shouldn't affect member functions.

Originally posted by @gregmarr in #1334 (comment)

I've had a somewhat radical and dubiously feasible idea of simply getting rid of free functions altogether in Syntax 2. This is an established language design practice, as e.g. in Java and C#.

Obviously, the biggest hurdle for the feasibility of this in cppfront is main. But I've considered this with the perspective of having recently worked on a moderately sizeable C++ codebase, and other than main, the only two contexts in which free functions are implemented are:

1. Windows service and DLL functions,
2. a macro for generating an enum class along with free functions for converting/obtaining its values to/from (w)strings.

I see 1. as perhaps unfortunate, but something we're already used to - even in Syntax 1, occasionally some compatibility C code is needed. Analogously, in Syntax 2, occasionally some compatibility Syntax 1 code might be needed.

As for 2., this use case is already eliminated by using cppfront's @enum metafunction.

So as far as I'm concerned, the only remaining stumbling block is main. But if this idea has any merit, I hope someone might come up with an elegant solution for this, because I'm drawing blanks. One potential downside (depending on perspective) is that "hello world" itself will necessarily become even less C++-like than it currently is.

Or maybe main can remain as the sole exception to this. That's not perfect, but it may be the most elegant.

---

Will your feature suggestion eliminate X% of security vulnerabilities of a given kind in current C++ code?
No.

Will your feature suggestion automate or eliminate X% of current C++ guidance literature?
If free functions with deduced returned types can't be made order independent, then this would enable fully achieving order independence and will automate/eliminate any guidance which that in itself automates/eliminates. I think this is also worthwhile with regards to reducing concept count.

Describe alternatives you've considered.
If, however, free functions with deduced returned types can be made order independent, this idea becomes mostly moot.

[MaxSagebaum]

I did not follow the discussion in #1334 closely, but what about static member functions. Would they work to?

@gregmarr would your comment hold for static member functions?

[gregmarr]

I assume that static member functions behave just like regular member functions.

[gregmarr]

Evidence for my earlier statement:

free functions with deduced return types are not order-independent

https://github.com/hsutter/cppfront/releases/tag/v0.8.0

It naturally discourages their overuse for named functions, because it will more often cause a compiler warning or error:

an error that a deduced return type makes the function order-dependent, when the function is called from earlier in the source file... this is because a deduced return types creates a dependency on the body, and it is inherent (not an artifact of either Cpp1 or Cpp2)