I have a type that I defined like this:

r = m_engine->RegisterObjectType("SValueBuilder", 0, asOBJ_REF); assert(r >= 0);

Now consider the following AS code:

void Test1(SValueBuilder &in builder)
{
	Test2(builder);
}

void Test2(SValueBuilder &in builder)
{
}

This actually throws this error at me which I did not expect, considering it's passed as a reference:

[WRN] [11:41:38] ERR  : scripts/main.as (line 3, column 8)
[WRN] [11:41:38]      : No appropriate opAssign method found in 'SValueBuilder' for value assignment
[WRN] [11:41:38]      : Previous error occurred while attempting to create a temporary copy of object

Why is it trying to copy the object if it's passing it as a reference? Is this a bug, or am I overlooking something?

I recall seeing in code that "&in" parameters are copied to make sure they are not used for output as well and checking the docs it does actually mention this:
https://www.angelcode.com/angelscript/sdk/docs/manual/doc_script_func_ref.html
"Input references are written as &in. As the reference is meant as input only, the actual value it refers to normally is a copy of the original so the function doesn't accidentally modify the original value. These are not commonly used, as they provide little benefit over passing arguments by value. Only in some circumstances can the performance be improved, especially if the parameter is declared as const too."

Ah, I see. I still think the difference between &in, &out, and &inout is a strange concept to have in the language, but maybe that's just me. By that paragraph, I assume "const Type &in x" doesn't copy the object, because it's const anyway?

3 hours ago, Miss said:

Ah, I see. I still think the difference between &in, &out, and &inout is a strange concept to have in the language, but maybe that's just me. By that paragraph, I assume "const Type &in x" doesn't copy the object, because it's const anyway?

I agree. But unfortunately it is necessary to keep compatibility with C++ native functions while still providing safe memory management in the scripts.

The compiler will avoid a copy of 'const type &in' when it is possible to guarantee the lifetime of the object, for example the object is a local variable. The copy is still made when the life time is not guaranteed, e.g. when being an element in an array.