If it truly were a bad idea, the already implemented (standard DLLs) feature wouldn't have existed to begin with.
The four standard DLLs are all from the same API set, and are very unlikely to ever export two
different functions with the same name from different files. (But you do have to be careful when omitting the A/W suffix, since there are cases like SHGetFileInfo, which has its ANSI version exported as SHGetFileInfoA
and SHGetFileInfo.) If you further expand that to other standard Windows DLLs, there are functions exported by the same name from different DLLs, but they
redirect to the same code.
taking into consideration [...] parameter types and count
How does it help to consider parameters? Generally functions are exported with C linkage; i.e. just a name. There is no function overloading in C or DllCall; if they have the same name, there is a conflict. Having a different parameter count might help to detect the error, but only for stdcall (x86). Even if the parameter types are the same, even if the purpose of the function is the same, it won't necessarily be safe to use in conjunction with other functions that are present in one of the conflicting DLLs but not the other.
That aside, I agree with your overall argument. Also, another reason to allow this convenience is that
Windows API sets have stupidly long names. For example, the functions for dealing with Windows Runtime strings are like this:
Code: Select all
WindowsGetString(hstr, ByRef len := 0) {
p := DllCall("api-ms-win-core-winrt-string-l1-1-0.dll\WindowsGetStringRawBuffer"
, "ptr", hstr, "uint*", len, "ptr")
return StrGet(p, -len, "UTF-16")
}
If #DllLoad adds every DLL to the list, the further toward the end of the list a DLL gets, the longer it will take to resolve its functions. Without load-time optimization, this could be quite costly. With it, the cost will be only once per DllCall
call site, rather than each time DllCall is called.