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

Z>и вправду, подстановка T в шаблон swap никак не ломает сигнатуру ... стандарт ничего не говорит о том, что swap должен использовать std::enable_if и проверять тип T на is_move_constructible и is_move_assignable, поэтому сигнатура функции не "пострадала" и SFINAE ничего "не заметил"... а при попытке инстанциировать swap (в первом закомменченом куске) мы, разумеется, обломались в теле функции и std::swap была выкинута из списка кандидатов.
Z>мой предидущий опыт

Автор: zaufi
Дата: 23.07.13

подсказывает

Автор: zaufi
Дата: 24.07.13

, что decltype() это unevaluated context -- т.е. туловище std::swap даже не пытаемся анализировать...

decltype это не полноценная проверка на компилируемость выражения со всеми внутренностями, а всего лишь "SFINAE-check" на стероидах.
Поэтому и появляются такие proposals как assert_static_failure.

Z>но тысяча чертей! как же тогда быть? если decltype норовит обмануть!??

А что ему делать в случае когда определение специализации в другом TU?

Z>ну фиг с ним с std::swap -- выкрутился тем, что сам проверяю что T должен быть is_move_constructible и is_move_assignable -- значит std::swap сработает, но если представить что-то более навороченное... ну не знаю, допустим какой-нить шаблонный алгоритм, требующий определенных свойств у итератора и элементов...

Так ведь в документации всё равно придётся указывать требования к типам. Или как пользователь должен понять что от него требуется?
Грядущие концепции (ЕМНИП Страуструп говорил что голосование будет в ноябре) должны как раз помочь с описанием требуемых свойств, автоматической перегрузкой и синтаксисом.
Кстати, AFAIK у концепций requires expression работает по тем же правилам что и SFINAE, то есть там по идее swap для not_swappable также пройдёт проверку requires.