Открою страшную тайну, БИК это чисто российское изобретение, зарубежные счета работают по-другому.
Есть SWIFT, есть иные системы - например в эуропе для перевода достаточно номера аккаунта.
Попробуйте завести счет в забугорном банке или там пейпал может какой у них работает.

Я профильнул, тормозит спавн процессов на моей машине как то: вызов vswhere, вызов cl.exe (чтобы получить его версию). Можно немножко ускорить путем кеширования инфы при вызове clang-cl probe (так как мы уже делали примерно те же вызовы когда сетапили msvc), но большого выигрыша это не даст. Хотя процентов 10 тоже бонус=).
Еще тормозят регэкспы в gccProbe (ноги растут из buildCompilerNameFilters) - это еще процентов 10.

Ну 6 секунд тоже дофига, нет?=)

Я заметил, что qbs setup-toolchains --detect стал тормозить на венде (28 секунд). kuzulis, не замечал? Может это связано с изменениями с баре метал?

Ну в .get() проверка не нужна, так как operator= "реализован" через implicit ктор от T и уже там есть проверка, т.е. нельзя nullptr присвоить.
Я так понял, эта проверка там с давних времен и пока не убрана "как бы чего не случилось".
Так как не ясно что этот get() должен возвращать для вумных указателей - ну а вдруг там будет ссылка на вумный указатель и можно сделать .get().release()?
Так-то да, сейчас эта проверка просто оверхед безо всяких бонусов (так как вумные не поддерживаются до конца).

С перемещаемым юником всё хорошо) проблема с его мутабельностью - либо он мутабельный и перемещаемый, либо немутабельный и неперемещаемый.

На самом деле, с юником проблемы "нулевого" указателя обычно нет - он обычно создается через make_unique и если избегать явных вызовов .reset(), то всё будет хорошо.

Кого мы пытаемся ограничить, запрещая писать gsl::not_null<int *> p = nullptr? Писателя функции?

То есть по-хорошему нужен какой-то immutable_unique_ptr который нельзя занулить, но можно мувнуть. Такого нет и сделать стандартными средствами нельзя => возникает нужда в not_null.

Ну это тоже следствие того что ctor принимает копию указателя а get() возвращает копию.

Но да, с вумными указателями это особо не нужно.
Кроме того, там лезут проблемы, например:

Конечно, повторный вызов get() выявит нарушение контракта, но хотелось бы запретить такой вызов "на корню", т.е. get() вообще в идеале не должен ничего проверять (контракт был нарушен где-то ДО get() и вот там это и надо проверять - в кторе ли или в операторе=)
Возможно, это можно сделать через частичную специализацию для разных типов - одна для тривиальных T*, вторая для вумных (т.е. get() возвращает всегда T* просто в случаев вумных делает еще один .get()). Короче всё оказалось не так тривиально как я думал=(

И правда, с юником оно не работает.

Я, кстати, еще наброшу - юник_птр вообще говно, его нельзя сделать объявить константным.
Юзкейз - мочь форвардить его в функции но запретить явно вызывать .release().
"константный" юник_птр бы решил все проблемы=)

К сожалению, не пользуюсь=( Только недавно перешли на с++17 моими стараниями (был с++11), а gsl хочет с++14 минимум. В ближайших планах есть.
gsl:span юзал, вот это вещь, да.
С умными указателями вроде всё неплохо, почему нет?

gsl::not_null поддерживается основными статическими анализаторами (clang и мелкософтным). Удачи сделать свой велосипед=)

Я как-то пришел на собеседование студентом в контору где меня срезали на том что я не привык проверять аллокацию памяти. Эти чувачки писали if (ptr) после ptr = new QTreeWidgetItem. Nuff said.