Yes I agree on 100% that it's unnecessary to pass handles by &in reference.

But such signature is a part of ScriptArray addon API: when we create a variable of

type array<IItem@> the find method

(whose signature is int find(const T&in if_handle_then_const value) const)

will actually have the find(const IItem@ &in if_handle_then_const value) const signature.

It seems there is no any method to avoid such a situation in array<>.

To my information, that is incorrect. If you attempt to query the signature of the method, it's actually "int array::find(Item@const&in value) const" (or likely "int array::find(const Item@const&in value) const" in the WIP version I am not using). Notice the const qualifier in front of "&in", meaning that the handle should be passed by const &in reference rather than just &in, and thus it's possible to avoid creating a copy of the handle. The same signature would not be considered valid in other contexts, i.e. outside of templates. As such, outside of templates it is unnecessary and actually somewhat inefficient to use the signature you're using.

Yes I agree on 100% that it's unnecessary to pass handles by &in reference.

But such signature is a part of ScriptArray addon API: when we create a variable of

type array<IItem@> the find method

(whose signature is int find(const T&in if_handle_then_const value) const)

will actually have the find(const IItem@ &in if_handle_then_const value) const signature.

It seems there is no any method to avoid such a situation in array<>.

To my information, that is incorrect. If you attempt to query the signature of the method, it's actually "int array::find(Garland@const&in value) const" (or likely "int array::find(const Garland@const&in value) const" in the WIP version I am not using). Notice the const qualifier in front of "&in", meaning that the handle should be passed by const &in reference rather than just &in, and thus it's possible to avoid creating a copy of the handle. The same signature would not be considered valid in other contexts, i.e. outside of templates. As such, outside of templates it is unnecessary and actually somewhat inefficient to use the signature you're using.

Checked again 5 min ago:

asITypeInfo *ti = engine->GetTypeInfoByDecl("array<T>");
asUINT countMethods = ti->GetMethodCount();
for (asUINT i = 0; i < countMethods; i++) {
      asIScriptFunction *func = ti->GetMethodByIndex(i);
      const char *decl = func->GetDeclaration();
      ...

And the result is:

"int array::find(const T&in) const"

Version 2.31.2 WIP with last fixes.

Yes, but that doesn't relate at all to what I claimed. Notice how in C++ too, the signature "int find(const T&)" for T = int* would become "int find(int* const&)" and not "int find(const int*&)". Instantiation of a template is more than just replacing every "T" with the type name. You should be checking the signature for the type array<Item@> if you want to determine anything.

Yes, but that doesn't relate at all to what I claimed. Notice how in C++ too, the signature "int find(const T&)" for T = int* would become "int find(int* const&)" and not "int find(const int*&)". Instantiation of a template is more than just replacing every "T" with the type name. You should be checking the signature for the type array<Item@> if you want to determine anything.

Yes, but for variable like "array<IItem@> items" the GetGlobalVarDeclaration(...) returns "IItem@[] items" and etc.

So I think it's necessary to ask an AS author (hi, Andreas :)) if internally the instantiation works same way as in C++.

It works similarly to C++.

...

Thank you, Andreas!

Thank you for discussion, Sir Ementaler!