C# - Method Group, Natural Type, function_type
아래의 문서 내용을 잠시 살펴보겠습니다.
Natural (function) type
; https://github.com/dotnet/csharplang/blob/main/proposals/csharp-10.0/lambda-improvements.md#natural-function-type
우선, "
method group"은 동일한 메서드 이름을 갖는 메서드들의 집합을 의미합니다. 가령, System.String 타입에는 2개의 ToString 메서드가 있는데요,
// System.String
public override String ToString();
public String ToString(IFormatProvider? provider);
따라서, "string.ToString"이라고만 하면 2개의 메서드로 이뤄진
method group을 일컫는 것입니다. 이러한
method group은 그 그룹 내에 있는 모든 메서드의 signature가 동일할 때 "자연 타입(natural type)"을 가질 수 있습니다. 따라서 당연히 1개의 메서드만을 가진
method group은 "자연 타입"을 가지는데요, 그런데 2개 이상의 메서드에서 "자연 타입"을 가질 수 있는 경우가 있을까요?
이러한 좋은 사례가 바로 확장 메서드를 가진 경우입니다. 가령, 다음과 같이 정의되었을 때,
internal class Program
{
static void Main(string[] args)
{
Class1 c = new Class1();
Action action = c.Call;
}
}
public class Class1
{
public void Call() { }
}
1개의 "void ()" signature를 갖는 Call 메서드는 당연히 "자연 타입"을 가지게 되지만, 저 Call 메서드 대신 다음과 같이 확장 메서드를 정의해도,
internal class Program
{
static void Main(string[] args)
{
Class1 c = new Class1();
Action action = c.Call; // 이전 예제의 Class1.Call과 동일한 메서드 시그니처를 가지는 확장 메서드
}
}
public class Class1
{
}
public static class Class1Extensions
{
public static void Call(this Class1 c) { }
}
마찬가지로 Call 확장 메서드의 시그니처는 "void ()"에 해당합니다. 따라서 저 2개가 함께 정의되었다면,
public class Class1
{
public void Call() { }
}
public static class Class1Extensions
{
public static void Call(this Class1 c) { }
}
2개의 메서드를 가진
method group이 "자연 타입"을 갖는 유형이 되는 것입니다. 이렇게 "자연 타입"을 갖는 Method group의 특징이라면 Signature가 동일하므로 타입 추론이 가능해 "var"로 받을 수 있게 됩니다.
즉, 위의 예제에서 "Action action = c.Call;" 대신 "var action = c.Call;"로 받아도 컴파일러가 알아서 "var"를 "Action"으로 추론해주는 것입니다. 그런데, 자연 타입을 갖는 method group에 저렇게 2개의 메서드가 있다면 어느 것을 컴파일러는 바인딩 시킬까요? 이에 대해서는
C# 7.3부터 적용된 규칙에 따라, (2번 항목의 규정으로) "an instance receiver"가 있으므로 정적 멤버가 제외돼 Class1.Call로 바인딩이 됩니다.
이것은 다르게 말하면, 자연 타입을 갖지 못하는
method group은 타입 추론을 할 수 없다는 것과 같습니다. 위에서 예를 들었던 string.ToString는, 2개의 메서드를 가진
method group이지만 서로 signature가 달라 "자연 타입"을 가지고 있지 않은 경우입니다. 따라서 var 추론을 할 수 없어 다음의 코드는 오류가 발생합니다.
var toStr = string.ToString; // error CS8917: The delegate type could not be inferred.
재미있게도, 자연 타입을 갖는다고 해서 꼭 타입 추론이 되는 것은 아닙니다. 일례로 아래의 코드에서는,
public class Class1
{
}
public static class Extensions1
{
public static void Call(this Class1 c) { }
}
public static class Extensions2
{
public static void Call(this Class1 c) { }
}
Class1.Call method group에 2개의 메서드(Extensions1.Call, Extensions2.Call)가 있고 그것의 signature가 같아 자연 타입을 갖지만 이에 대해서는 타입 추론을 할 수 없습니다.
// error CS0121: The call is ambiguous between the following methods or properties: 'Extensions1.Call(Class1)' and 'Extensions2.Call(Class1)'
var z = new Class1().Call;
당연하겠죠? ^^
익명 타입 역시 "자연 타입"을 가질 수 있는데요, 이를 위해서는 매개변수와 반환 타입이 모두 명시적으로 선언돼 타입 추론이 가능해야 합니다. 예를 들어, 아래의 익명 함수는,
() => default
자연 타입을 가지고 있지 않습니다. 왜냐하면 매개변수가 없는 것은 명시되었지만 반환 타입을 알 수 없기 때문인데, 이로 인해 타입 추론이 불가능합니다.
// 컴파일 오류: error CS8917: The delegate type could not be inferred.
var func = () => default;
하지만, 타입 추론을 하지 않는다면? 즉, 동일한 익명 함수 코드임에도 불구하고 받는 측에서 타입을 지정해 사용할 수는 있습니다.
Func<int> func = () => default;
저 익명 함수가 자연 타입을 가지려면, 매개변수는 명시했으므로 반환 타입만 명시해 주면 됩니다.
int() => default
이로써 자연 타입을 갖는 익명 함수는 타입 추론에 사용할 수 있습니다.
var func = int() => default;
혹은, 반환 타입을 이렇게 명시해도,
() => (short)5;
타입 추론이 가능해 var에 대입할 수 있습니다.
var func = () => (short)5;
// var == Func<short>
따라서, 저 익명 함수 역시 자연 타입을 갖는 유형입니다.
문서에 따르면, method group이나 익명 함수가 자연 타입을 갖는다는 것은 곧 타입 추론이 가능하냐에 대한 중요한 척도가 됩니다. 그리고 이럴 때의 "자연 타입(natural type)"은 곧 메서드의 signature에 해당하는 "
function_type"이 됩니다. 달리 말해, 같은 signature를 가진 method group이나 익명 함수는 같은 "
function_type"을 가지게 되는 것입니다.
C# 언어에서
function_type은 다음과 같이 제한적인 문맥에서만 사용된다고 하는데,
- 암시적/명시적 형변환 (implicit and explicit conversions)
- 메서드 타입 추론과 공통 타입 선택 (method type inference (§11.6.3) and best common type (§11.6.3.15))
- var 타입 추론 (var initializers)
한 가지 유의할 점은,
function_type은 컴파일 시에만 내부적으로 정의돼 사용하는 것일 뿐, 컴파일된 결과물에 메타데이터로 출력되거나 소스코드상에 존재하는 것은 아니라는 점입니다.
이와 함께
function_type이 아닌 모든 경우에는
function_type으로의 형변환이 불가능합니다. 또한 위의 조건에서 "명시적 형변환"을 언급했지만 (소스코드상에 존재하지 않는 관계로) 원래 (개발자에 의한 cast operator를 사용한) 명시적인 형변환은 존재하지 않습니다.
function_type이 암시적 형변환이 가능한 상황은 크게 다음과 같이 3가지 경우가 있습니다.
- function_type F의 매개변수와 반환 타입이 안전한 가변 규칙으로 function_type G로 변환 가능할 때,
- System.MulticastDelegate 또는 그것의 기본 타입으로,
- System.Linq.Expressions.Expression 또는 System.Linq.Expressions.LambdaExpression 타입으로,
첫 번째 유형의 경우, 그동안의 경험으로 볼 때
가변성에 관해 매개변수는 반공변으로, 반환 타입은 공변인 경우를 의미하는 듯합니다. 문서에서는 그에 관한 예시 코드가 없는데, 저도 딱히 어떻게 예를 들어야 할지 모르겠습니다. ^^; 추측으로, 굳이 예를 들자면 아마도 컴파일러가 메서드를 선택하는 기준이 적당할 것 같은데, 가령, signature가 정확하지 않더라도 다음과 같이 가변이 허용되는 경우일 듯합니다.
public class BaseType
{
}
public class DerivedType : BaseType
{
}
public class Class1
{
public DerivedType? CallMethod(BaseType arg)
{
return default;
}
}
Class1 c = new Class1();
DerivedType arg = new DerivedType();
BaseType? result = c.CallMethod(arg); // 가변이 허용되는 CallMethod의 바인딩
혹은, 원래 이렇게 델리게이트로 받는 것이 정상이지만,
Func<BaseType, DerivedType?> func1 = c.CallMethod;
이렇게 가변이 허용되는 경우도 암시적 형변환이라고 볼 수 있을 것입니다.
Func<DerivedType, BaseType?> func2 = c.CallMethod;
위의 경우 사용자가 호출에 명시한 CallMethod의
function_type은 "BaseType? (DerivedType)"이지만, 가변 규칙에 따라 안전하게 형변환이 가능한 "DerivedType? (BaseType)"이 가장 적합한 후보로 선정될 수 있고, 이를 통해 컴파일러 내부에서는 암시적 형변환이 이뤄졌다고 볼 수 있을 것입니다. (혹시, 이와 관련된 정확한 사례를 알고 계신 분이 계시다면, 덧글로 의견 부탁드리겠습니다. ^^)
암시적 형변환이 가능한 나머지 2개의 경우는 문서에서 예시 코드를 제공하고 있으니 어렵지 않게 이해할 수 있습니다. 우선, Delegate의 경우에는 다음과 같이 암시적 형변환이 가능합니다.
// 암시적 형변환의 2번째 조건에 해당: System.Delegate 타입은 System.MulticastDelegate의 부모 타입
System.Delegate d = short(int arg) => { return default; };
// 암시적 형변환의 2번째 조건에 해당: System.Object 타입은 System.MulticastDelegate의 부모 타입
object obj = short (int arg) => { return default; };
// 비록 경고는 발생하지만 암시적 형변환으로 컴파일은 가능
object objMethod = "".Clone; // warning CS8974: Converting method group 'Clone' to non-delegate type 'object'. Did you intend to invoke the method?
위의 코드에서 object 형변환 코드를 잠시 짚고 넘어가 볼까요? ^^ 이런 경우 만약 Clone 대신 ToString을 대입하면 오류가 발생합니다.
// error CS8917: The delegate type could not be inferred.
object objMethod = "".ToString;
왜냐하면, 이전에 언급했듯이 System.String 타입에는 2개의 ToString 메서드가 있고, 결국 해당 method group에는 "자연 타입"이 없으므로
function_type이 정해지지 않아 암시적 형변환이 불가능한 것입니다.
참고로, Clone의 경우조차도 그것이 유효한 구문이긴 하지만 의도한 경우는 아닐 것이므로 컴파일 경고를 발생시킨다고 합니다. 단지, 그것이 개발자가 의도한 것이라면 (object)로의 형변환 연산자를 사용해 경고를 없앨 수 있습니다.
object objMethod = (object)"".Clone; // 경고 없음
자, 그럼 마지막 규칙에 해당하는 System.Linq.Expressions.Expression (및 그것을 상속한 System.Linq.Expressions.LambdaExpression)으로 암시적 형변환이 허용되는 코드는 이렇게 예시를 들 수 있습니다.
// 암시적 변환의 3번째 조건에 해당: System.Linq.Expressions.Expression 또는 System.Linq.Expressions.LambdaExpression으로 변환 가능
System.Linq.Expressions.Expression exp = short (int arg) => default;
System.Linq.Expressions.LambdaExpression exp2 = short (int arg) => default;
끝으로,
function_type의 변환은 C#이 정한 암시적/명시적
표준 변환은 아니라고 합니다. 결국, 표준 변환이 아니므로
사용자 정의 변환 연산자를 통해
function_type의 변환을 제어할 수 없습니다. 다시 말해, 애당초 그 연산자의 대상 자체로 간주되지 않는다는 의미입니다.
이에 대한 예제로 다음과 같은 예시가 나옵니다.
class C
{
public static implicit operator C?(Delegate d) { return default; }
}
C c;
c = () => 1; // error CS1660: Cannot convert lambda expression to type 'C' because it is not a delegate type
c = (C)(() => 2); // error CS1660: Cannot convert lambda expression to type 'C' because it is not a delegate type
"() => 1" 익명 함수는 "자연 타입"을 가진 유형으로
function_type이 정해집니다. 따라서, "Delegate d" 인자로는 암시적 형변환이 가능합니다.
Delegate d = () => 1;
하지만, 그 타입의 변환은 표준 변환이 아니므로 implicit/explicit operator의 대상으로 간주되지 않아 아예 implicit operator 자체가 바인딩 후보 메서드 그룹에 끼지도 않아 오류가 발생합니다.
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]