4 ms·

Namespaces by themselves aren't a reason why name mangling is needed. There isn't a technical reason why foo::x couldn't be the symbol name, literally. (Not sur

Namespaces by themselves aren't a reason why name mangling is needed. There isn't a technical reason why foo::x couldn't be the symbol name, literally. (Not sure what ELF and PE/COFF etc would think of these names in current implementations). Name mangling is needed if you want to overload functions and qualify them only by the types (not names) of their in and out parameters. This is where it gets ugly on the binary level.

jcelerier 4y ago
> There isn't a technical reason why foo::x couldn't be the symbol name, literally. how do you do when you want to access your C function from a language which is binary-compatible with C but uses :: for something else? [a-zA-Z_][a-zA-Z0-9_]* identifiers are the only thing that the whole world more-or-less standardized around. e.g. in fortran you can directly import a C function and call it. But "::" in the middle of a function name would very likely fail (I don't know enough fortran to tell for sure but given how the syntax looks...): subroutine foo (a, n) bind(c) import real(kind=c_double), dimension(*) :: a integer (kind=c_int), value :: n end subroutine foo allows to call a "void foo(double *a, int n);" function defined in C. I imagine that subroutine ns::foo (a, n) bind(c) would likely not work
- zozbot234 4y ago
  > how do you do when you want to access your C function from a language which is binary-compatible with C but uses :: for something else? Typically you'd do this by picking a different internal name for the function, and putting the external symbol in quotes.
- jstimpfle 4y ago
  Fair point. The C naming convention with flat names is quite conservative and consequently allows the names to be used directly from most other languages without any language-aware mapping / compatibility layer.
zozbot234 4y ago
Rust doesn't allow function overloading. Name mangling is used there to implement linking multiple versions of an external module into the final build.
- tialaramex 4y ago
  Although Rust doesn't have ad-hoc polymorphism, it does have polymorphism, and so it needs to track multiple versions of the same function anyway. Take String::contains(). The equivalent feature in C++ is an overloaded function, so there are I believe it's three, versions of this function which take different parameters: A string, a char and a pointer to chars, they do similar things in practice but the compiler has no idea, there are just three functions with the same name. However the Rust feature is polymorphic, there are N versions of this function depending on what monomorphisations are chosen at compile time. The compiler knows these are all the same function, but the parameters have different types in practice at runtime and so the generated machine code is different. If your program can String::contains(cat_photo_jpg) then the compiler will produce the code to call it with your Jpeg type or whatever and it will need to keep it distinct from the version where it takes a String or a char or whatever. Rust does this more often than C++ because it cannot choose ad hoc polymorphism. So if there should be a foo function which can take parameters bar, baz or quux, we need to decide either that bar, baz and quux all implement some trait which foo takes, or we need three separate functions foo_with_bar, foo_with_baz and foo_with_quux.
  - throwaway17_17 4y ago
    This question is very OT considering the what TFA is about, but… What does the term ad-hoc polymorphism mean in your comment? Are you saying Rust does not have ad-hoc polymorphism because the syntax acts like the function in parametrically polymorphic and only once monomorphisation occurs are the different functions per argument type are generated is it N different functions. Does this line of thinking also say Haskell does not have ad-hoc polymorphism? And in case any reader wonders, I am genuinely interested in your response to these questions (i.e. this isn’t bait nor rhetorical).
    - 4y ago

jcelerier 4y ago

> There isn't a technical reason why foo::x couldn't be the symbol name, literally. how do you do when you want to access your C function from a language which is binary-compatible with C but uses :: for something else? [a-zA-Z_][a-zA-Z0-9_]* identifiers are the only thing that the whole world more-or-less standardized around. e.g. in fortran you can directly import a C function and call it. But "::" in the middle of a function name would very likely fail (I don't know enough fortran to tell for sure but given how the syntax looks...): subroutine foo (a, n) bind(c) import real(kind=c_double), dimension(*) :: a integer (kind=c_int), value :: n end subroutine foo allows to call a "void foo(double *a, int n);" function defined in C. I imagine that subroutine ns::foo (a, n) bind(c) would likely not work

zozbot234 4y ago
> how do you do when you want to access your C function from a language which is binary-compatible with C but uses :: for something else? Typically you'd do this by picking a different internal name for the function, and putting the external symbol in quotes.
jstimpfle 4y ago
Fair point. The C naming convention with flat names is quite conservative and consequently allows the names to be used directly from most other languages without any language-aware mapping / compatibility layer.

zozbot234 4y ago

Rust doesn't allow function overloading. Name mangling is used there to implement linking multiple versions of an external module into the final build.

tialaramex 4y ago
Although Rust doesn't have ad-hoc polymorphism, it does have polymorphism, and so it needs to track multiple versions of the same function anyway. Take String::contains(). The equivalent feature in C++ is an overloaded function, so there are I believe it's three, versions of this function which take different parameters: A string, a char and a pointer to chars, they do similar things in practice but the compiler has no idea, there are just three functions with the same name. However the Rust feature is polymorphic, there are N versions of this function depending on what monomorphisations are chosen at compile time. The compiler knows these are all the same function, but the parameters have different types in practice at runtime and so the generated machine code is different. If your program can String::contains(cat_photo_jpg) then the compiler will produce the code to call it with your Jpeg type or whatever and it will need to keep it distinct from the version where it takes a String or a char or whatever. Rust does this more often than C++ because it cannot choose ad hoc polymorphism. So if there should be a foo function which can take parameters bar, baz or quux, we need to decide either that bar, baz and quux all implement some trait which foo takes, or we need three separate functions foo_with_bar, foo_with_baz and foo_with_quux.
- throwaway17_17 4y ago
  This question is very OT considering the what TFA is about, but… What does the term ad-hoc polymorphism mean in your comment? Are you saying Rust does not have ad-hoc polymorphism because the syntax acts like the function in parametrically polymorphic and only once monomorphisation occurs are the different functions per argument type are generated is it N different functions. Does this line of thinking also say Haskell does not have ad-hoc polymorphism? And in case any reader wonders, I am genuinely interested in your response to these questions (i.e. this isn’t bait nor rhetorical).
  - 4y ago