We can easily reference internal functions that are used as call targets by using their function index. Imported functions also have a function index and can therefore also be referenced. It is possible though to have call targets from other modules that are passed as function references and either saved in a table or called via call_ref.
In the current design, these cannot be added despite there potentially being valid use cases where we might want to know about those targets. Ideally, the first implementation would reserve the possibility to reference such external functions later. But it's unclear how to even uniquely express such external functions.
We don't have unique identifiers for modules and things like URL of the module are web-specific, don't apply to all potential module instantiations (e.g. sync/async instantiations) and are not stable over time as module contents from the same URL might change re-ordering the functions and changing their behavior.
We could also introduce the option of adding a unique identifier to the header of a module which needs to be updated every time the module changes. This is hard to enforce though and might require some alignment to avoid collisions.
Hashes are more reliable, but don't guarantee that two modules are indeed equivalent if they have the same hash. Since the functionality of the program is not affected by inlining, this should not be a security issue but would only result in suboptimal performance if someone tried to actively tamper with the module content while keeping the same hash. Unintended hash collisions are extremely unlikely.
So the best option might be to keep the option of adding a hash to the function index and just associating the current module with a hash value of 0.
There is also the possibility that references go back and forth and any added compilation hint will change the module requiring an update in the dependent module and results in cycles. This could be avoided by excluding the compilation hints section from hash computation, but other sections might have similar implications.
We can easily reference internal functions that are used as call targets by using their function index. Imported functions also have a function index and can therefore also be referenced. It is possible though to have call targets from other modules that are passed as function references and either saved in a table or called via
call_ref.In the current design, these cannot be added despite there potentially being valid use cases where we might want to know about those targets. Ideally, the first implementation would reserve the possibility to reference such external functions later. But it's unclear how to even uniquely express such external functions.
We don't have unique identifiers for modules and things like URL of the module are web-specific, don't apply to all potential module instantiations (e.g. sync/async instantiations) and are not stable over time as module contents from the same URL might change re-ordering the functions and changing their behavior.
We could also introduce the option of adding a unique identifier to the header of a module which needs to be updated every time the module changes. This is hard to enforce though and might require some alignment to avoid collisions.
Hashes are more reliable, but don't guarantee that two modules are indeed equivalent if they have the same hash. Since the functionality of the program is not affected by inlining, this should not be a security issue but would only result in suboptimal performance if someone tried to actively tamper with the module content while keeping the same hash. Unintended hash collisions are extremely unlikely.
So the best option might be to keep the option of adding a hash to the function index and just associating the current module with a hash value of 0.
There is also the possibility that references go back and forth and any added compilation hint will change the module requiring an update in the dependent module and results in cycles. This could be avoided by excluding the compilation hints section from hash computation, but other sections might have similar implications.