Разрешение метода ограничения общего компилятора Roslyn VS2019 - PullRequest
Новая
       12

Разрешение метода ограничения общего компилятора Roslyn VS2019

2 голосов
/ 17 мая 2019

Недавно мы обнаружили проблему в нашей кодовой базе, где скомпилированный код VS2019 в порядке, но VS 2017 не удался.

Я создал метод расширения для Union, который имеет общий ISet в качестве общего ограничения 

using System;
using System.Collections.Generic;
using System.Linq;
public static class Extensions
{
    public static S Union<S, T>(this S self, IEnumerable<T> other) where S : ISet<T>, new()
    {
        //For simplicity issues since this is a compilation based question
        return default(S);
    }

    public static void Test()
    {
        var values = new[] { 1, 2, 3 };
        var values1 = new[] { 1, 2, 3, 4 };

        values.Union(values1);
    }
}

Union генерирует ошибку компиляции, утверждая, что int [] не конвертируется в ISet.

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

Я не видел нигде в примечаниях к выпуску, в которых говорится, что они исправили эту ошибку или добавили новую функцию для улучшения разрешения методов для универсальных методов.

Я ищу больше информации по этому вопросу, Было ли это исправлением Microsoft или предполагаемой функцией?

1 Ответ

4 голосов
/ 17 мая 2019

Это часть C # 7.3 (так что вы можете использовать его и в VS 2017, если вы указали версию 7.3).Это задокументировано в заметках о выпуске C # 7.3 :

Улучшенные кандидаты на перегрузку

В каждом выпуске правила разрешения перегрузки обновляются доадресовать ситуации, когда неоднозначные вызовы методов имеют «очевидный» выбор.В этом выпуске добавлены три новых правила, которые помогут компилятору выбрать очевидный выбор:

  1. ...
  2. Когда группа методов содержит несколько общих методов, аргументы типа которых не удовлетворяют их ограничениям,эти члены удалены из набора кандидатов.
  3. ...

Раньше это не было ошибкой - оно подчинялось спецификации языка;Я не знаю, почему спецификация изначально была написана именно так, как здесь.Возможные причины:

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