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

V>Т.е. dst уже ложен быть на момент создания. А как через такой синтаксис выразить:
V>

V>SomeClass b = ....
V>//...
V>SomeClass a = b + SomeClass(...); // такое?
V>

Такое прекрасно работало и до move-семантики через RVO…


V>

V>SomeClass a = ....
V>func(std::move(a)); // такое?
V>

Такой, на мой вкус, вообще сомнительно. Смотри, например, вопрос о том, с чего началась эта ветка...

V>А что делать если нам не повезло и у dst нет конструктора по умолчанию? И src у тебя превращается в такое же зомби с неопределенным состоянием. Так чем же твой подход лучше?
Тем, что не надо усложнять язык...
Хуже то, что в этом раскладе move-семантика ничем не лучше, но сложнее

Если что, то в этой подветке вроде обсуждалось то, что косяки дизайна контейнеров STL на богоданные, а вполне могут быть выпрямлены при желании...
IMHO, это очевидно.

Но я в плоском режиме читаю, могу подветки спутать...

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

V>Т.е. dst уже ложен быть на момент создания. А как через такой синтаксис выразить:
V>

V>SomeClass b = ....
V>//...
V>SomeClass a = b + SomeClass(...); // такое?
V>

Такое прекрасно работало и до move-семантики через copy elision…


V>

V>SomeClass a = ....
V>func(std::move(a)); // такое?
V>

Такой, на мой вкус, вообще сомнительно. Смотри, например, вопрос о том, с чего началась эта ветка...

V>А что делать если нам не повезло и у dst нет конструктора по умолчанию? И src у тебя превращается в такое же зомби с неопределенным состоянием. Так чем же твой подход лучше?
Тем, что не надо усложнять язык...
Хуже то, что в этом раскладе move-семантика ничем не лучше, но сложнее

Если что, то в этой подветке вроде обсуждалось то, что косяки дизайна контейнеров STL на богоданные, а вполне могут быть выпрямлены при желании...
IMHO, это очевидно.

Но я в плоском режиме читаю, могу подветки спутать...