The no ambiguity will be harder as you start to introduce more conversions.fxm wrote:In the single scope (if no ambiguity) retained after a procedure name look-up, then, an overload resolution is applied in addition if necessary.marcov wrote:
But if a symbol is marked overload, also search deeper ?
But then you are limited in cross scope overloading. This means that it is very hard to e.g. add an overloaded variant of a function to a set that is e.g. already defined in system and let it be transparent to the user (without detailed scope setup).I think the current process (similar to the one of C ++ for example) simplifies the problem by dealing with it in two successive phases:
- selection of a single scope among all those which are accessible by only taking into account the symbol name regardless of the arguments supplied by the caller (if at least two scopes containing the symbol name have equivalent accessibility priority => ambiguity).
- within this single scope retained, one final overload resolution taking into account the full signature.
The problem is thus simplified to one single full overload resolution within a same scope (instead of a full overload resolution within each scope candidate, and then the difficult choice of the best result among the scope candidates).
Such a process uses the principle of 'name hiding'.
But yes, if you don't do it, you search much more scopes, and the operation is more expensive/slower. But only if you don't find an exact match. Then it reduces to making finding an exact match cheaper (e.g. compare with hash of a normalized signature), and only when not found do full resolution