There’s “mangling” where symbols have an underscore put in from of them. But I think the point is that namespaces functions would need to be mangled and thus be difficult to call.

> But I think the point is that namespaces functions would need to be mangled

Namespaces don't need to be mangled at all if they are interpreted as symbol prefixes.

I'd prefer that, say, namespace foo::bar resolved into foo_bar for all symbols (even that meant risking namespace naming collisions) to not having any support for namespaces in C.

In fact, this approach is already used to implement pseudo-namespaces, so that wouldn't be much of a stretch.

What's the point? How is typing foo::bar better than typing foo_bar?

It seems like you want the language to be more complicated for no benefit. Why not use C++ at that point?

> What's the point? How is typing foo::bar better than typing foo_bar?

You're missing the whole point of namespaces. The goal is not to replace foo_bar with foo::bar. The whole point is that within a scope you can type bar instead of foo::bar, or bar instead of foo::baz::qux::bar, because you might have multiple identifiers that might share a name albeit they are expected to be distinct symbols.

https://en.wikipedia.org/wiki/Namespace

> What's the point?

using namespace kind::ofa::long_name;

or

using kind::ofa::long_name::bar;

is the point.

As far as I know, name mangling only exists because linkers don’t have a notion of namespaces. If you fix linkers, then there is no need to mangle.

And also because of function overloading in, say, C++. To link code two functions with the same identifier which differ only in signature (e.g. types of arguments), we need to pass them to linker as two different functions with different identifiers.