И ещё, если бы список был длинным, я бы применил макрос ко всем строкам через Vi}:normal @w<Enter>, а не считал бы строки.

Записываю макрос копирования, перевода в верхний регистр и перехода на начало следующей строки. 2@w выполняет макрос ещё два раза. Затем копирую блок в фигурных скобках (можно было не переходить для этого в визуальный режим, это просто привычка), заменяю в скопированном блоке const test = на import (опять же, можно было сразу без него скопировать). Далее dWj.j. удаляет из каждой строки фрагмент до пробела. Ну и добавляю from './entity-base'.

Я бы как-то так делал:
jqwwwywWvlpvbgU0jq2@wV%yO<Esc>Pc3wimport<Esc>j^dWj.j.ja from './entity-base'

Ещё как вариант можно растягивать окно на два монитора :)

А потом какой-нибудь код, не знающий разницы между квадратом и прямоугольником меняет созданному Square width.

Да, извиняюсь, немного запутался. void* не является pointer-to-object type, но является object pointer type.

The type of a pointer to void or a pointer to an object type is called an object pointer type.

Тогда reinterpret_cast<void*> и reinterpret_cast<void**> полностью валидны.

Однако void* не является object pointer type.
Если не ошибаюсь, по стандарту каст между object pointer и void pointer может выполняться только со static_cast, хотя по факту любой компилятор reinterpret_cast тоже съест.

У нас повсеместно используются смарт-поинтеры, а эта проверка видимо недостаточно умная, чтобы ругнуться на деструктор unique_ptr.

gcc 9.1.0
С -Wnon-virtual-dtor действительно ловит, -Wall -Wextra -Wpedantic оказывается недостаточно.

Во-первых, мне почему-то ни gcc -Wall -Wextra -Wpedantic, ни даже clang-tidy ничего не сказали, а во-вторых мой комментарий был вообще не об этом.

Я вообще не пишу на Rust, только интересуюсь :)
Как мне кажется, выделение unsafe блоков — как раз очень полезная с точки зрения безопасности фича. А мой комментарий выше — контраргумент к Вашему утверждению, что Rust безопасен тем, что UB проявляется (не)определённым образом.

С моей точки зрения это наоборот, жирный минус к безопасности. UB именно тем и плох, что проявляется в неожиданные моменты и тяжело отлавливается.

В C++ тоже сплошь и рядом UB проявляется гораздо позже, чем происходит. Например, у нас недавно был случай, когда приложение начинало зависать через пару часов работы после того, как объект был удалён по указателю на интерфейс, в котором не было виртуального деструктора.

У меня так (time из zsh):

bash -c 'for i in ./*  ./.* ; do echo $i ; done'  0.01s user 0.00s system 97% cpu 0.011 total

bash -c 'echo ./* ./.*'  0.01s user 0.00s system 96% cpu 0.009 total

tree -aiL 1  0.01s user 0.00s system 96% cpu 0.010 total

find . -maxdepth 1 -mindepth 1  0.01s user 0.00s system 95% cpu 0.008 total

du -ad 1 .  1.46s user 17.90s system 6% cpu 4:38.79 total

tar -cvf /dev/null --no-recursion ./* ./.* 2> null  0.12s user 0.00s system 90% cpu 0.134 total

perl -e   0.01s user 0.00s system 23% cpu 0.024 total

python  0.03s user 0.01s system 90% cpu 0.034 total

rsync --list-only ./  0.01s user 0.01s system 82% cpu 0.016 total

ls --color=auto  0.01s user 0.01s system 5% cpu 0.259 total

ls --color=no  0.01s user 0.00s system 95% cpu 0.009 total

Мне кажется или в вариантах с глобами правильнее делать time bash -c '...', чтобы время разворачивания глобов тоже учитывалось?

«yes» подразумевает, что бывает «no»

Интересно, о чём будет думать программист, который напишет свой enum class no, в расчёте на то, что с ним будет другой результат? Или Вы имеете в виду, что символ no может чисто случайно оказаться в том же scope, и программист воспользуется им, не посмотрев?

Q — рациональные числа, IEEE 754 ассоциировать с каким-то алгебраическим множеством неразумно.

И почему так мало языков вводят возможность определять числа большие чем 256 bit? Q64Kbit

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

В nim можно объявить несколько переменных одного типа как
var a, b, c: int

Ещё способ с включенной Compose Key: Compose,",U.

В каком-то смысле да, но для программиста выглядит ближе к многопоточной парадигме, в частности доступно ветвление кода внутри потока (реализуется выполнением обеих ветвей и применением маски).

А в NVIDIA Volta планировщик уже даже может при необходимости разделять потоки и вести для каждого отдельный стек и счётчик инструкций. Оптимизацией под Volta я пока не занимался, так что не могу сказать, насколько сильно это в реальности меняет подход к программированию.