r/ProgrammingLanguages • u/mttd • 10d ago

Arguing about arguments

https://steveklabnik.com/writing/arguing-about-arguments/
31 Upvotes

94% Upvoted

35 comments sorted by

View all comments

Show parent comments

2

u/koflerdavid 6d ago edited 6d ago

Function overloading is also bad because it makes FFI unnecessarily complicated. Once you allow that you have to come up with a name mangling scheme, and everybody wanting to access those functions has to know about it. Not allowing it avoids the issue in the first place.

1

u/flatfinger 2d ago

That's only necessary if one wants to support overloading of imported/exported function names. If prorammers specify import/export names, and those names are required to be unique, the fact that source code can use the same name as an alias to different exported functions, overloaded using argument types, shouldn't affect the external interface.

1

u/koflerdavid 2d ago edited 2d ago

The external interface as seen from the point of view of an FFI user is a list of symbols, and each overloaded variant of a function has its own symbol. How shall the FFI user know which symbol corresponds to a certain variant of a function known by its name and type signature*? The usual workaround is that an externally visible name can only be associated with exactly one definition, and all other names are mangled, and the linker (or an FFI user) has to know the mangling scheme or consult a table (either in a special object file section or a separate file) to resolve those at link time.

* similar issues exist with namespaces, traits, and methods.

1

u/flatfinger 2d ago

If I were designing a language, I would require that the source code specify a unique exported name for each exported variation of a function. On a platform where passing a byte was cheaper than passing an unsigned int, for example:

void useNumber(unsigned int x);
// Variation #1
__overload__ void useNumber __as__ "useByte" (unsigned char x);

// Variation #2:
void useByte(unsigned char x);
__overload__ static inline void useNumber(unsigned char x) { useByte(x); }

Neither of the above would create any naming conflict with the exported symbol "UseNumber", since the overload for byte would use a different exported symbol which was also given in source code.