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

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

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

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

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

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

Тут попытка изменить константный объект, естественно он сопротивляется. Это ко всем типам относится, не только unique_ptr такой плохой. Если нужно обеспечить, чтобы в указателе всегда был какой-то объект, то это не обязательно связано с иммутабельностью. У него поведение может отличаться (нет release(), reset(nullptr) и прочее). При этом можно заменить управляемый объект на другой, сделать swap с другим указателем и т.д. Т.е. нужен именно какой-то not_null_unique_ptr.

Если такого стандартного нет, значит нужно сделать нестандартный .

Например, когда какой-то объект (составной/composite) уникально владеет точно одним другим объектом (частью/part) и нужно соблюдать целостность этой связи. Чтобы явно сказать, что в этом указателе точно есть объект, и не нужно этот указатель проверять на null, а можно сразу к нему обращаться. В отличие от optional_unique_ptr(std::unique_ptr), где объект может быть, а может и не быть, и тогда перед обращением к указателю его обязательно нужно проверить. Если обратиться к UML, то not_null_unique_ptr может реализовать конец ассоциативной связи с композитной агрегацией и кратностью [1..1], в то время как .  optional_unique_ptr тоже может реализовать композитную агрегацию, но уже с кратностью [0..1]. Как в этом примере.

А, ну судя по "нельзя занулить, но можно мувнуть", то, возможно, нужно выразить в типе параметра функции, что в этом указателе точно есть объект, можно не проверять на null, нельзя удалять объект из этого указателя (но можно ли заменить на другой?), как-то поработать с этим объектом, передать владеющий указатель дальше (в другую функцию, в поле класса, возможно в очередь команд/событий) и в текущей функции забыть про него. Т.е. функция может и не быть конечной остановкой. Такая у меня версия, но могут быть и другие .

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