I'm desperately trying to understand what you're trying to ask... Could you repeat that?

Are you asking why they didn't just use the function signature instead of a mangled name?

Well, one immediate downside would be that it would require the linker to have a full subset of a C++ parser embedded in order to extract the relevant data from the name (enough of C++ parser to understand function headers, not trivial when you think of all the possibilities). Name mangled names are far simpler and faster for the linker to decode since they have a much simpler syntax.

And when a compiler vendor adds an extension keyword that can be used in function declarations (e.g. restrict), the linker also has to be updated so it understands. Not to mention needing to also update any other tools that read .obj or .o files and output data.

So disadvantages, yes. Do you see any advantages to your approach?

Why would you care about how readable a mangled function name is? By the way, the return value is not part of the function signature (special case!) except in some cases in C++ related to templating (more special cases!).

Readability is non-issue. Humans do not read .obj files.

I think you should concentrate on getting your super-C language producing conventional .obj files before you start redesigning the link stage :)

Readability is non-issue. Humans do not read .obj files.

And for when they do, we have lovely debug tools that can either unmangle the symbol names directly, or map those symbol names back to their readable counterparts by looking up debug information.

im speaking about c (forgot to mention).

// normal header declaration
[[linkname="foo_ic"]]
extern void foo(int, char);

[[linkname="foo_df"]]
extern void foo(double, float);

// another file could do this and be compatibile
extern void foo_df(double, float);

// and yet another could use the same extension
[[linkname="foo_ic"]]
extern void foo(int, char);

Readability is non-issue. Humans do not read .obj files.

I think you should concentrate on getting your super-C language producing conventional .obj files before you start redesigning the link stage

yeah.

conventional linkers only support single-part symbol-names, and often with a fairly constrained character space (A-Z, a-z, 0-9, _, sometimes others).

ideally, you also don't want them to be unnecessarily long/verbose.

it also makes sense to be able to extract the name and signature if needed, ...

name-mangling schemes are then usually designed around these limitations.

for example, we might have a hypothetical name mangling scheme which might encode:

void foo(int, float);

as, say:

_Z3fooEif

or:

_XC_foo_4if_5v

or:

...

types may be encoded with a scheme like, say:

lower-case letters signal the end of a type-name ('i' for int, ...);

upper-case letters signal complex or special types;

...

for example, "char *" might be encoded as 'Pc' and "unsigned char **" as 'PPh', ...

likewise, we might represent some special type, for example, "_Complex long double &" as "RCe".

...

side notes:

my VM actually internally uses a type-signature and name-mangling scheme derived from a mix of the (IA64 / GCC 3.x / ...) name mangling, and also the JVM and JNI signature and mangling schemes.

for example, internally one might have a name and a signature, say "foo" and "(if)v", but if these need to be written into an object file, they will be combined ("foo(if)v") and then a prefix is stuck on and any special characters are escaped.

likewise, "var x;" may become "x;r" and then "_XF_x_2r" (*1).

where: "_XF_" is the magic to identify it as a mangled name, and also encodes the type of symbol ("XF" for global-variables/static fields, "XC" for ordinary functions/methods, "XM" for VM-provided pseudo-instructions, "XN" for metadata, ...).

otherwise, '_' is used as an escape, which may be used to encode various other characters, for example, "_0xxxx" for a unicode char, or "_9xx" for a random ASCII char, with others for various special characters ( _ ; [ ( ) / ] , ).

*1: actually, this case shouldn't actually happen: top-level and package-level variables don't actually (currently) exist as globals, but are implicitly put inside objects (as per-instance fields, the top-level and each package are given objects, internally as "dynamic classes"). it is more likely to happen as a result of a static class field, but then we would have a name more like "_XF_somepackage_6SomeClass_6x_2r"

typically the fully-mangled names only really exist in native-compiled or JIT-compiled output though (they don't exist for code in bytecode form).

there is a bit more than this, but this is the basic idea at least...