Почему ограничение EventArgs было удалено из EventHandler ‹TEventArgs›?

В .NET Framework 2.0 делегат EventHandler получил общее обобщение, позволяющее второму аргументу иметь не только тип EventArgs, но и производный тип, налагая более жесткие ограничения на его реализации. Но когда-то в .NET Framework 4, скорее всего в .NET Framework 4.5, общее ограничение было удалено, согласно комментарию I найдены как в справочном источнике, так и "https://github.com/dotnet/runtime/blob/2024b63acd460edeb53b2ce6984710ab51c11f2f/src/coreclr/src/mscorlib/src/System/EventHandler.cs" rel = "nofollow noreferrer". Источник среды выполнения NET.

// Licensed to the .NET Foundation under one or more agreements.
// The .NET Foundation licenses this file to you under the MIT license.

namespace System
{
    public delegate void EventHandler(object? sender, EventArgs e);

    public delegate void EventHandler<TEventArgs>(object? sender, TEventArgs e); // Removed TEventArgs constraint post-.NET 4
}

Но какой был смысл в снятии ограничения и, таким образом, нарушении совместимости с существующими пользователями? Или, чтобы привлечь к ответственности даже кого-то, кто не входит в команду .NET, что могло быть такой мотивацией?

Я столкнулся с этим архаичным изменением из-за правила SonarQube S3906, которая выглядит как копия устаревшего CA1009 и требует, чтобы тип обработчика событий требовал EventArgs в качестве второго аргумента. Теперь это противоречит CA1003, что требует использования универсального EventArgs ‹TEventArgs›. Я решил подавить проблему с помощью EditorConfig, так как я не могу изменить профиль качества в SonarQube, но мне все еще не понятно, зачем вообще понадобилось это критическое изменение.

Я видел очень похожий вопрос, который задавали раньше в рамках отличного вопроса относительно отклонения EventHandler ‹TEventArgs›, а также в отдельный вопрос, но на мой вопрос там не ответили. Их вопрос заключается в том, почему ограничения нет (текущее состояние), я спрашиваю, почему оно было удалено (причина изменения), что немного по-другому, потому что причина должна быть достаточно сильной, чтобы оправдать изменение.


person Palec    schedule 31.05.2021    source источник
comment
Я не понимаю, почему это что-то ломает: если обработчик имеет подпись void (object, EventArgs), его все еще можно передать конструктору универсального EventArgs<TEventArgs>, единственное, что ломается, это то, что void (object, object) теперь компилируется там, где не было раньше.   -  person Charlieface    schedule 01.06.2021
comment
Я думал о двоичной совместимости и ситуации, когда двоичный файл вызывает обработчик событий, например, EventArgs.Empty, а после изменения определения EventHandler ‹TEventArgs› больше не гарантируется, что EventArgs.Empty является допустимым значением. Но теперь, когда я немного подумал, я не могу придумать сценарий, когда это приведет к обратным результатам. :-( Здесь уже довольно поздно и у меня был тяжелый день, нужно будет подумать об этом еще утром.   -  person Palec    schedule 01.06.2021