std::pair

писать руки болят

Верни тюпл в чем проблема?

тогда можно сразу бросать C++

Ну в прочем я так и сделал, слишком вербозно

Все так просто?))) Я думал там возвращать последовательность функций))

F[T => U]

"Вы не понимаете, это другое".

А хочется?

А в каком языке это сделано не через туплы?

возвращай тупл/структуру, в чем проблема?

Чего хочется? Сахара?

Во флудилке случайно родилась мысль. Иногда хочется иметь строгие тайп-алиасы.

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

// our header

// На самом деле это какая-то 
// сложная инстанция шаблона, 
// для которой мы не можем  
// сделать форвард-декларацию
struct Foo;

std::shared_ptr<Foo> foo_ptr;

// our cpp file

// нужный нам шаблон
#include <foo>

struct Foo 
    : libfoo::foo< libfoo::some_other_type
                 , libfoo::some_class::nested> 
{ using foo::foo; }

// Здесь мы можем свободно работать 
// с foo_ptr как с libfoo::foo, например:

int main() {
    foo_ptr->bar();
}

А теперь проблема. Ключевое слово final. Лично я для себя его как попытку помочь компилятору соптимизировать наш код, однако, его наличие так же бонусом ломает и код выше.

Есть мысль: а что, если бы ключевое слово final не запрещало наследование от класса, а только запрещало только перегрузку виртуальных функций (и возможно, расширение класса?)?

Тогда компилятор смог бы продолжить так же успешно оптимизировать код, но при этом не ломал бы представленный пример кода, который бы мог быть крайне полезен/удобен

Есть ли ещё какие-то действительно полезные применения ключевого слова final? Может ли в реальном коде понадобиться предотвращение наследования для других целей?

Пока что @Malbu0698 предположил, что это может сломать SFINAE, сделав ранее невалидный код валидным и, возможно, у кого-то сломаются какие-то трейты

Может ли кто-то высказать своё мнение о предложении? Возможно, кто-то увидит ещё какие-то подводные камни здесь?

По сути, это расширение существующего механизма, чтобы позволить делать строгие тайп-алиасы без какого-то нового синтаксиса

Можно ли как-то создать в векторе объект с удалёнными copy и move конструкторами?

emplace_back требует move конструктор

А зачем и как это может быть использовано?

не понятно как при расширении вектор должен это всё мувать | копировать

Можно:

vec.push_back(std::make_unique<std::mutex>());

vec.push_back(std::make_unique<std::mutex>());

Тут есть move конструктор

Есть класс, в котором запрещено и то и то по причине наличия коллбеков на него из других классов, содержащих указатель