Правильнее было бы назвать NamedCat, да

Но тогда у NamedCat и NamedDog общий интерфейс выйдет все равно

> зачем мне вообще дактайпинг?

Снижение издержек на измнение интерфейса. Если вы решили, что принимаемый объект у вас должен быть несколько иным, вы просто начинаете его использовать иначе, а все места, где функция вызывалась, будут помечены компилятором/IDE как места, требующие рефакторинг.

то есть вместо разумной ошибки "теперь вам требуется определить ещё одну функцию" все объекты начинают молча падать в рантайме? Каким образом это улучшение?

В компил тайме, не в рантайме. Мы же говорим о проверке утиной типизации компилятором.

Основная проблема с таким подходом в том, что будет юзабилити как в темплейтах у крестов.

кишки протикающие в сигнатуру это скорее минус чем плюс. Вон Copy/Send/Sync в расте протекают - посмотри сколько у людей боли от этого

ну почему NamedCat ?
impl NamedAnimal for Cat

Проблема и с темплейтами крестов и Copy/Send/Sync в Расте в том, что они плохо справляются с выводом ошибок для пользователя. Я согласен, что это непростая задача, но её можно было бы попробовать решать

проблема не только в ошибках. А когда контракт плавает туда-сюда

про семвер слышал? В нем получается что ты вот что угодно изменил в теле - и это ломающее изменение. Обычно изменения в сигнатуре так делают, а тут тело поменял - и херак, всех своих клиентов разломал

собственно с Send проблема не в том что ошибка плохая

а в том что в принципе апдейт зависимости на патч может тебе сломать компиляцию, потому что челик решил "ну если я тут футуру буду локально запускать то ничего страшного, у меня же impl Clone в возвращаемом значении", а внезапно где-то че-то развалилось.

У меня так было когда я с футурами развлекался. Сигнатура одна и та же у двух фунок, но одна работает а другая нет

потому что тело разное

и вот фиг угадаешь на что из твоих кишков завяжется кто-то снаружи

способ описывать контракт который проверяется компилятором существует - называется "типы"

Ну, это непростая задача, я согласен. Плавающий контракт означает, что программу можно понять так, а можно этак. Компилятор по факту(и в силу правил семантики языка) выбирает какой-то определенный путь, и выдает ошибку в соответствии с ним, хотя фактически ты мог иметь ввиду что-то совершенно иное(то есть пойти по иному пути). Фактически нам нужен более умный компилятор, который более глубоко способен понимать суть того, что ты пытался неявно выразить. Повторюсь, что это непростая исследовательская задача, но тут есть пространство для исследования, как мне кажется.

Данный вопрос во многом завязан на проблему останова, как я уже писал ранее. Не в том смысле, что компилятор должен определить буквально, остановится ли программа, а в том смысле, что компьютерная программа в общем случае не может оценить логическую корректность другой программы. В "динамических" языках(я пишу в кавычках, потому что сама характеристика динамического приведения типов тут не при чем на самом деле) решают эту проблему просто игнорируя её. Языки программирования с условно статической системой типов в действительности пытаются решать проблему путём введения более простого(в плане вычислительной сложности) метаязыка типов. Поскольку этот язык(ну, не беря в рассчет завтипы, само собой) обладает более низкой вычислительной сложностью, его проще проверить. Тем не менее сам подход по своей сути является эвристикой. И тут важно понимать, что таких эвристик может быть бесчисленное множество. Конкретно именно та эвристика, которая предлагается мейнстримовыми системами типов является всего лишь одной из возможных альтернатив среди бесчисленного множества других. И не обязательно является наилучшей.

а по-моему оно называется "документация"

Да, кстати. Если бы нам хватало только лишь типов, мы бы вообще не писали документацию :)