Здравствуйте, Galiulin Rishat Faimovich, Вы писали:

GRF>>>В нашей нотации необходимо несколько изменить вызов и определение:

KO>>И получить другое поведение? Нет уж, так не пойдёт, боюсь, небольшим изменением тут не отделаться.

GRF>Нет вы получите именно то поведение которое желаете, попробуйте.

Но позвольте, конструкторы класса 'in' принимают константную ссылку на значение аргумента, мне же нужно передавать аргумент по-значению, для unique_ptr передача по константной ссылке и передача по значению это две большие разницы. Впрочем, я попробовал, как и ожидалось, "эквивалентный" код успешно компилируется, там где оригинальный (как и задумывалось) приводит к ошибке компиляции.

KO>>>>и не всегда применим:

KO>>>>

KO>>>>MyType z = in<MyType&>(in<MyType&>(a) + in<MyType&>(in<MyType&>(b) * in<MyType&>(c)));
KO>>>>

KO>>>>во что это превратится с использованием expression templates я даже думать не хочу, впрочем, как я понял, некоторым такой вариант кажется более читабельным по сравнению с

GRF>>>Мы и не планировали что in, in_out и out будут так применяться .

KO>>А как же ещё им применяться? Входные параметры есть, почему их не надо помечать? Впрочем, я, кажется, понимаю: благодаря удачным названиям функций способ использования передаваемых параметров очевиден, может, тогда, вместо изобретения велосипедов, стоит давать более удачные названия функциям?

GRF>Например в определении функции так:
GRF>

GRF>void function( in< MyType& > a, in< MyType& > b, in< MyType& > c )
GRF>{
GRF>   MyType z = a() + b() * c();
GRF>}
GRF>

MyType operator+( in< MyType& > lhs, in< MyType& > rhs )
{
    return ...;
}

что я делаю не так?

GRF>Для того чтобы писать:
GRF>

GRF>MyType z = a + b * c;
GRF>

GRF>надо будет перегрузить операторы.

ну да, надо будет, это вы к чему сказали?