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++.

int find(const T&in if_handle_then_const value) const

becomes

int find(const IItem @const &in value) const

for array<IItem@>. The keyword if_handle_then_const is what tells AngelScript to add the first const, otherwise it would be exactly as in C++, i.e. find(IItem @const &in value).

Observe, IItem@[] is an alias for array<IItem@> (if you've registered array<T> as the default array type).

The signature find(const IItem @const &in value) const is not really needed for normal script functions, as the same result can be accomplished with find(const IItem @ value). The only reason for the template instance to create the function with the first signature rather than the latter, is because the C++ implementation is the same regardless of the instantiated type, so the function signature must obey the registered signature, i.e. take a const reference to whatever subtype the template is instantiated for.

It works similarly to C++.

...

Thank you, Andreas!

Thank you for discussion, Sir Ementaler!