Я хотел задать этот же вопрос, но, к счастью, ТАК нашел этот для меня.
Я могу понять точку зрения, что для этого потребуется, по крайней мере, новое ключевое слово или новая семантика для существующих ключевых слов, поэтому оно не поддерживается, поскольку экономическая выгода не работает в его пользу.
Однако я подвергаю сомнению, законно ли избегать реализации этой функции CLR из-за узкого варианта использования или потому, что это может смутить людей.
Один из аргументов, приведенных выше, заключается в том, что он используется только для обеспечения самодисциплины.
Но то же самое можно сказать и о любом модификаторе видимости, который не public. Идея о том, что это применимо только к «одному разработчику из одной библиотеки», также явно ошибочна. Многие библиотеки разрабатываются группами людей, и для разработчика внутри этой команды вполне естественно добавить члена, который он или она хотел бы ограничить только внутренними типами, производными от его или ее базы.
Тогда есть такой сценарий:
internal class Foo {
}
public class PublicBase {
protected Foo MyFoo { get; set; }
}
В данном случае у меня есть внутренний тип, который я хочу предоставить классу, но я хочу предоставить его только производным типам. Поскольку тип является внутренним, это неявно означает производные типы в той же сборке. Внешние типы могут по-прежнему законно наследоваться от этого типа, но им не нужно использовать этот член.
В этой ситуации я застрял: я не могу использовать protected и не могу использовать protected internal.
Вместо этого я должен использовать internal, который неправильно передает другим членам моей команды, что его следует использовать из кода вне класса. Конечно, я могу добавить комментарий (и даже прикрепить EditorBrowsableAttribute из Never к нему, но это также скрыло бы его от внутренних наследников) - но это не то же самое.
На самом деле, единственный способ добиться этого - взломать сборку с помощью перезаписи IL после сборки, но мне нужна эта видимость (или ее отсутствие) во время компиляции, а не после сборки.
В конечном счете, аргументы о "какие ключевые слова будут использоваться" или " как это будет реализовано " для меня не имеют значения: я программист, а не Дизайнер языка C #.
Точно так же я должен сказать, что аргументы типа «Ну, protected internal достаточно запутанный для многих» также не имеют значения. Есть так много разработчиков, с которыми я общался, лично или виртуально, которые не понимают такие вещи, как ?: или общие ограничения - угадайте, что они не используют их! Это не значит, что я не должен.
Так что да, я понимаю причины, по которым он не реализован - но я с ними не согласен - поэтому мой ответ о том, почему C # не поддерживает его, заключается в том, что дизайнеры C # ошиблись.
И да, я готов к теплу, которое может привести к моей двери:)