Здравствуйте, karbofos42, Вы писали:
K>Дописать это сейчас — 5 минут нудной, рутинной работы, т.к. я в контексте и знаю как всё работает.
K>Если не понадобится — я потерял 5 минут времени, бывает.
Помимо потери 5 минут времени, вы пишете код, который вы не знаете для чего нужен. У вас нет ни одной точки, в которой для вашей коллекции вызывается конструктор с нестандартным компарером.
Через полгода, когда вы поняли, что для вашей коллекции важно использовать какой-то конкретный компарер, у вас уже есть неизвестное количество кода, заточившегося под этот конструктор.
Вам придётся потратить часы и дни на исследоание этих зависимостей и проверку того, что убирание конструктора не сломает обратную совместимость.
Убирать код всегда дороже, чем его писать.

K>Если же понадобится через полгода, то я потрачу полчаса, а то и несколько часов.
На что вы потратите полчаса? На нажатие Ctrl+. и Generate method? Очень в этом сомневаюсь.
K>Потому что, сначала нужно разобраться во всех этих наследованиях, найти тот класс, где есть нужный конструктор, потом по всей иерархии его пробросить.
Звучит пугающе, но тут помог бы реальный пример. Потому, что на такие вещи, когда call site уже известен, уходят буквально секунды — go to definition, и поехали.
Добавить пустой конструктор — дело нескольких секунд, неважно сегодня или через полгода.
Главное — что добавление конструктора никакую обратную совместимость не ломает. Поэтому это дёшево.
Если у вас там цепочка наследования — ну умножим мы несколько секунд на 5. Да хоть на 10 — всё это совершенно тривиальные действия, большую часть которых выполняет IDE.

K>Это ещё при условии, что кто-то вообще задумается, что возможно где-то в недрах есть нужный конструктор, а не надстроит что-то сверху через фабрики или ещё какие-нибудь отличные паттерны.
Вот этот момент категорически непонятен. Какие ещё фабрики? Вы привели пример KeyedCollection — ну, покажите мне, как обойти отсутствие конструктора с IEqualityComparer при помощи фабрики.

K>Так с исключениями вполне нормальный пример.
Ок, то есть ваш пример с KeyedCollection был просто так?
K>Когда начинаешь библиотечные классы делать и заводишь свои типы исключений — постоянно эта писанина пустых конструкторов.
Да откуда она берётся-то???? Когда я пишу библиотечные классы и мне зачем-то надобятся мои собственные классы исключений, я никогда не пишу пустых конструкторов.
Весь смысл своих типов исключений — это возможность сконструировать их так, как удобно мне, а не фреймворку.
K>Либо сразу ленишься писать конструктор с innerException, а потом он внезапно становится нужен и возвращаешься дописывать.
Во-первых, если он "внезапно" становится нужным, то у вас что-то не так с проектированием. Вы же знаете, в каких случаях собираетесь бросать ваш Exception? Значит, знаете и потребность в innerException или в его отсутствии.
У вас и код, который его ловит, наверное будет заточен под наличие либо отсутствие innerException. Ну, а если всё же требования изменились на ходу — ну, ок, для такого редкого случая не грех и конструктор добавить, и пакет пересобрать.


K>Если это отдельная библиотека, то будет дополнительное веселье ради этого пересобирать nuget-пакет.
K>Не скажу, что прямо киллер-фича и без этого нельзя жить, но вроде нет проблем это добавить ни идеологически, ни технически.
Совершенно верно. И это можно сделать без изменения языка.