Здравствуйте, Sinclair, Вы писали:

S>Помимо потери 5 минут времени, вы пишете код, который вы не знаете для чего нужен.

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

S>У вас нет ни одной точки, в которой для вашей коллекции вызывается конструктор с нестандартным компарером.
S>Через полгода, когда вы поняли, что для вашей коллекции важно использовать какой-то конкретный компарер, у вас уже есть неизвестное количество кода, заточившегося под этот конструктор.

Так у меня нет ни одной точки или у меня неизвестное количество кода?
Если я не использую конструктор с кастомным комперером, а сегодня он мне понадобился — я в нужном месте добавил вызов и всё.
Если таки использую — значит он подавно был уже мне нужен и писал не зря.

S>Убирать код всегда дороже, чем его писать.

Зачем его убирать? Он есть, хлеба не просит.
А вот если класс был завязан на дефолтный компарер, а потом вдруг понадобился кастомный, вот тут может быть веселье с добавлением кода.
Ищи все проверки объектов и меняй их на вызов компарера.

S>Главное — что добавление конструктора никакую обратную совместимость не ломает. Поэтому это дёшево.

А какую совместимость ломает неиспользуемый конструктор?
Если был конструктор, принимающий IEnumerable<T>, а я добавлю конструктор, принимающий ICollection<T>, то там точно совместимость не сломается?

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

Создаём наследника от наследника KeyedCollection. Опять перегружаем в нём метод GetKeyForItem, чтобы он возвращал наследника ключа, для которого прописано правильное сравнение по умолчанию.
т.к. мы пишем по паттернам и всему такому, то вызов конструктора выносим в фабрику, которая будет возвращать либо исходного наследника с одним сравнением, либо его потомка — с другим.

К чему вот эти поиски реального примера на форуме?
Реальный код в большинстве своём коммерческий и принадлежит работодателю.
Чтобы показать масштаб трагедии — там нужно целый проект вывалить, а то будет опять, что пару конструктором нормально и вручную написать.
Да и там в итоге будет, что так не нужно писать, нужно всё отрефакторить, переделать, потратить неделю времени на то, чтобы обойти это.
Хотя исходный вопрос был в наследовании конструкторов.
Почему наследование методов — это нормально, а конструкторы — это плохо и неправильно, я так и не понял.