Это всё же неймспейс. При этом выглядит как обычный "стандартный" юник. Удобно и читаемо, по-моему

Для меня скрытые зависимости ухудшают читаемость, а специализация default_delete весьма вероятно окажется скрытой в файле реализации.

Это сообщение только укрепило меня во мнении, что это хорошая идея. В принципе, необходимость писать явный удалитель, особенно для класса, который предполагается использовать в подобном контексте, это лишние заботы для пользователя. Это значит тащить реализацию наружу. Предусмотреть же совместимость со стандартной RAII обёрткой... Впрочем, в общем случае действительно не лучший подход, ибо легко наткнуться на ODR violation. С другой стороны, модули могут изменить это... В общем, думаю, пока, если планируется этот код распространять это не лучшая идея, однако в определённых контекстах, как и всё, в принципе, вполне неплохое применение. Да и если необходимо настроить более гибко, чем "стандартное" решение, такая возможность всегда есть

Для частного случая и перегрузка операторов сработает.

Вот еще одни грабли: добавление специализации для Foo, который уже существовал потребует проверки всей кодовой базы на предмет использования unique_ptr<Foo>, поскольку специализация изменит поведение всех таких указателей. И это хорошо если есть что проверять - библиотечный код не сможет позволить себе этого никогда.

В общем если бы было голосование, я бы сказал strongly against.

Оно было :)
Ну, для библиотечного кода я и сказал, вероятно, не лучшая идея. С другой стороны модули, да.
А насчёт unique_ptr<Foo>... Я, собственно, предполагаю, что если нам понадобилась специализация, то и стандартный удалитель нам не подходит. А так, для данного Foo, в предположении того, что мы его поставляем, наша специализация и была бы стандартной.
К тому же мы делаем удобную глобальную точку кастомизации для всех юников нашего типа. Лишняя зависимость, конечно, с какой-то стороны, однако удобно.

Ну вот приняли этот пропозал. У меня был Foo. Я хочу добавить к нему специализацию. Но кто-то мог использовать unique_ptr<Foo> именно для того чтобы положить объект на хип. Да это маловероятно, но это код, который сломается.

Это не пропозал. Это уже существующая возможность. Впрочем, я согласен с тем, что это добавляет сложностей, если мы хотим работать именно с кучей

Вообще меня больше раздражает что не приняли пропосал на обобщение unique_ptr, которое позволяло хранить произвольный тип, а не только указатели. Кажется класс называелся unique_resource или что-то в этом роде.

И какая мотивация для отказа была? В принципе, он и правда несколько избыточен, но всё же

У меня нет инсайдов. Кажется в том же пропазале были скоуп гварды.

Я не уверен, что стандарт допускает это.

https://eel.is/c++draft/namespace.std#2
> (b) the specialization meets the standard library requirements for the original template

https://eel.is/c++draft/unique.ptr.dltr#dflt-4
Кастомный оператор вызова функции будет иметь другой эффект.

Но я уже не раз ошибался в толковании стандарта, поэтому моему мнению здесь нельзя доверять.

Ну, тут я согласен, под delete надо подвести. Или предполагается, что никаких эффектов кроме delete?

Моя интерпретация, что ожидается только вызов delete. Но я могу ошибаться.

Можете подсказать с архитектурой приложения ,с использованием CUDA?

/rules@GBReborn_bot

А что конкретно?
В хедере определяешь класс, в cpp’шнике пишешь реализацию класса и нужные глобал/девайс методы, которые дёргаешь из методов класса. Если ты об этом.

template <class Ty, class Dx>
unique_ptr(Ty*, Dx&&) -> unique_ptr<Ty*, Dx>;

template <class Ty, class Dx>
unique_ptr(Ty*, Dx&) -> unique_ptr<Ty*, Dx>

Тут достаточно одного, просто убери ссылку

Легально ли вызвать такую функцию в SFINAE-контексте?

template<typename T>
auto foo(T t) -> decltype(foo(t));

Или это if-ndr? Сейчас Clang/GCC/MSVC успешно компилируют следующий код:

template<typename T>
concept is_foo_invocable = requires {
   ::foo(std::declval<T>());
};

static_assert(! is_foo_invocable<int>);

Могу ли я полагаться на это?

Я не уверен, куда смотреть в стандарте на этот счёт. Очевидно, у нас тут нет рекурсивного инстанцирования, T у нас всегда один, а потому этот пункт мне кажется неприменимым. И я не уверен, что есть смысл смотреть ограничения на constexpr-функции, тогда речь об unevaluted expression. Куда ещё стоит обратить внимание — я не знаю

Это уб