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

C>>Кстати, а как ты вообще собрался реализовывать бактрекинг поверх ридера?
S>Аккуратно

Судя по твоей попытке отмолчаться, делаю вывод, что до тебя наконец дошло, какую глупость ты понаписал.

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

C>Судя по твоей попытке отмолчаться, делаю вывод, что до тебя наконец дошло, какую глупость ты понаписал.
Да, сначала я было подумал, что можно обойтись без бактрекинга, но понял, что не выйдет.
А ридер, увы, откатываться назад не умеет. Так что вы правы — я выбрал неудачный пример.

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

S>Я пока не понял, как сделать так, чтобы при регистрации нового SourceGenerator/Analyzer остальные анализаторы не сворачивались трубочкой.

Подождать еще 20 лет. МС обязательно все сделает. Заменит генераторы на макросы и сделает поддержку IDE.

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

C>есть внятные объяснения?

Конкретизирую чей то ответ. Подкласс — это более специализированная версия базового класса и созданный унаследованным конструктором экземпляр подкласса, может оказать не валидным. Пример:

  public class Class1
 {
     private string _property;

     //любой string
     public string Property
     {
         get { return _property; }
     }

     public Class1(string property)
     {
         _property = property;
     }
 }

 public class Class2 : Class1
 {
     public Class2(string property) : base(property)
     {
         //теперь только string не равный null
         if (property == null)
         {
             throw new ArgumentNullException(nameof(property));
         }
     }
 }

Если бы экземпляр класса Class2 мог бы создаваться вызовом конструктора класса Class1, то созданный экземпляр был бы не валидным .

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

VD>Заменит генераторы на макросы

Что уже сделано, переделывать не будут. Такая у них ментальность.

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

Q>может оказать не валидным

Значит, сделать это опциональным. Где проблема?

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

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

Q>>может оказать не валидным

C>Значит, сделать это опциональным. Где проблема?

Проблема в том, что по ошибке это может работать не правильно, а тогда зачем давать такую возможность.

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

νsb>Проблема возникает, когда нужно что-то не совсем тривиальное. К примеру в конструктор базового класса нужно передавать два параметра.
Уже пилят, скоро будет https://openjdk.org/jeps/492

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

Q>Проблема в том, что по ошибке это может работать не правильно, а тогда зачем давать такую возможность.

Неправильный код обычно работает неправильно. Сюрприз!

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

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

Q>>Проблема в том, что по ошибке это может работать не правильно, а тогда зачем давать такую возможность.

C>Неправильный код обычно работает неправильно. Сюрприз!

Вот-вот, поэтому не правильно давать возможность написать такой код.

Здравствуйте, Qulac, Вы писали:
Q>Конкретизирую чей то ответ. Подкласс — это более специализированная версия базового класса и созданный унаследованным конструктором экземпляр подкласса, может оказать не валидным.
Ничуть не споря с вашим утверждением, хочу ещё дополнить теоретической идеей, имеющей практическую реализацию.
В том случае, если у Class2 нет собственных конструкторов, то можно с уверенностью сказать, что его автор не имел в виду никаких новых инвариантов.
Тогда возможным решением было бы принудительное наследование в него всех доступных конструкторов Class1, а не только default constructor.
Ведь ничего особенного в дефолтном конструкторе нет.

И, на минуточку, ровно такой подход применён в TypeScript. Если нет своих конструкторов — получаем в подарок конструкторы предка.
Вполне удобно для всяческих маркерных классов, которые отличаются только результатом вызова instanceof.
Абстрактный сферический пример в вакууме:

abstract class Expr {}

class ConstExpr<T>
{
    constructor(value: T)
    {
        this.value = value;
    }
    value: T
}
abstract class BinaryExpr extends Expr
{
    constructor(left: Expr, right: Expr)
    {
        super();
        this.left = left;
        this.right = right;
    }

    left: Expr;
    right: Expr;
}

class Addition extends BinaryExpr {}     // обращаем внимание на 0 лишних строк
class Subtraction extends  BinaryExpr {}

function t()
{
    var a = new Addition(new Subtraction(new ConstExpr(42), new ConstExpr(17)), new ConstExpr(447));
}

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

S>Здравствуйте, Qulac, Вы писали:
Q>>Конкретизирую чей то ответ. Подкласс — это более специализированная версия базового класса и созданный унаследованным конструктором экземпляр подкласса, может оказать не валидным.
S>Ничуть не споря с вашим утверждением, хочу ещё дополнить теоретической идеей, имеющей практическую реализацию.
S>В том случае, если у Class2 нет собственных конструкторов, то можно с уверенностью сказать, что его автор не имел в виду никаких новых инвариантов.

Дело не только в конструкторе, переопределено могло быть c новым инвариантом само свойство.

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

C>Что уже сделано, переделывать не будут. Такая у них ментальность.

Ты наивный. В любом продукте всегда есть фатальный недостаток.

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

Q>Дело не только в конструкторе, переопределено могло быть c новым инвариантом само свойство.
А это как раз ничему и не противоречит. Сеттер-то будет вызываться от нового класса.

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

VD>Ты наивный. В любом продукте всегда есть фатальный недостаток.

В этом случае, скорее сделают новый язык. Как водится, со своими новыми косяками.

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

Q>Вот-вот, поэтому не правильно давать возможность написать такой код.

Ну тогда тебе остается только запретить писать код вообще.