Короче, слив по полной

я почитал комментарии и таки надо признать, что я ошибался.
Стефан прав и код работает именно так, как должен.

ограничивая параметр классом TTest1 мы говорим о том, что параметры будут являться наследниками TTest1 и соо-но в коде можем использовать только методы и свойства TTest1. ожидать, что внутри обобщённого класса можно будет использовать другие методы из классов наследников абсолютно неправильно (а ведь по факту TTest2.Test - это абсолютно другой метод и не имеет ничего общего с одноименным методом из TTest1).

Простой пример: если мы добавим метод TTest2.OtherTest мы же не сможем его вызывать из обобщённого кода, тк такой метод отсутствует в базовом классе.

ты ошибался, я ошибался. :) а почему? потому что работает не очевидно. очевидно, что статический тип при специализации заменяется на аргумент. и он заменяется, но не совсем.
а правильно это считается потому что так работает в C#. эталон у них такой

Ник, не бузи ))

😝

по мне дак все встало на свои места.
как бы ты поступил в таком случае на месте компилятора?

type
 TTest1 = class
   procedure Test();
 end;

 TTest2 = class(TTest1)
   procedure OtherTest();
 end;

 TTest<T: TTest1, constructor> = class(TObject)
   FTest: T;
   procedure TestIt();
 end;

procedure TTest1.Test();
begin
 WriteLn('1');
end;

procedure TTest2.OtherTest();
begin
 WriteLn('2');
end;

procedure TTest<T>.TestIt();
begin
 FTest := T.Create();
 FTest.OtherTest();
 readln;
end;

begin
 with TTest<TTest2>.Create do
   TestIt();
end.

я кстати подзабыл, что методы, реализующие интерфейс не обязаны буть виртуальными. а невиртуальный вызов меня устроит. но пока я вижу таки виртуальный :(

тут очевидно не скомпилируется, за неимением метода

твой случай - это тоже самое, за исключением совпадения имен методов.
так что всё честно, как ни крути.
ну и хорошая новость - в женериках под делфи снова нет багов 🙂

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

ну и не ругаться по поводу отсутствующих операторов, если код специализирован типом, у которого они есть. хотя тут чуть сложнее, т.к. дерево до специализации не построишь так просто

это как минимум создает неоднозначность.
2 класса, 2 одноименных метода.

во-первых, неоднозначность она все равно на месте. во-вторых она есть в рантайме, а во время компиляции ее нет

в общем, я таки считаю, что все честно  и менять ничего не надо, что собственно  и будет в итоге с вероятностью 99%.
но все равно было интересно 🙂

с такой же вероятностью ничего не поменяли бы даже если там прям баг был :)

а по поводу интерфейсов и невиртуальных вызовов у тебя работало?

ну не, баги правят, особенно если на них обратить должное внимание и обосновать.
@ziv_2006 не даст соврать

а в чем суть, я видимо пропустил.
в идеале с примером

суть в том, чтобы TTest1 сделать интерфейсом. тогда вызывается нужный метод. и как говорил ты, да и тот же Стефан должно вызываться как невиртуальный метод. но пока что я вижу нечто похожее на виртуальный вызов. хотя сам метод без virtual

встречный вопрос - а почему ты так стараешься избежать виртуального метода?