Page 30 -

택적 매개변수 등의 다른 기능과도 연관되어 있다. 이 부분은 사실 언어 명세의 내용 중 가장 까다
6
로운 부분이기도 하며, 옳고 그름을 판단하기도 어렵다.
2
다행스럽게도 세부적인 내용을 완벽히 이해하지 못해도 일반적인 코드를 작성하는 데는 크게 지장
이 없다. 다만, 타입 추론을 수행했을 때 발생할 수 있는 추론의 세 가지 가능성과 대안은 알아 두자. C# 2

● 타입 추론에 성공하고 원하는 결과를 얻는 경우. 만세!
● 타입 추론에 성공했지만 원하는 결과가 아닌 경우. 명시적으로 타입 인수를 지정하거나 인
수를 타입 변환하자. 예를 들어 Tuple.Create를 호출하여 Tuple<int, object, int> 타입
의 객체를 생성하고 싶다면, Tuple.Create를 호출할 때 타입 인수를 명시적으로 지정하거나

new Tuple<int, object, int>(…)과 같이 객체를 생성하거나 Tuple.Create(10, (object)
"x", 20)과 같이 호출하면 된다.

● 컴파일 타임에 타입 추론을 실패한 경우. 때때로 인수를 타입 변환하여 문제를 해결할 수 있
다. 예를 들어 null 리터럴(literal)은 타입을 가지지 않으므로 Tuple.Create(null, 50)과 같
이 호출하면 타입 추론에 실패한다. 하지만 이 경우 Tuple.Create((string) null, 50)과
같이 코드를 작성하면 문제를 피할 수 있다. 그 외의 다른 경우에는 타입 인수를 명시적으로

지정하면 된다.

마지막 두 가지의 경우에는 제안한 방법을 적용하더라도 가독성에 크게 영향을 미치지는 않을 것
이다. 타입 추론에 대한 세부 사항을 완벽하게 이해하고 있다면 어떤 경우에 타입이 올바르게 추
론되고 어떤 경우에 그렇지 않은지를 쉽게 예측할 수 있겠지만, 이를 위해서 상당한 시간을 투자

하여 언어 명세를 완벽히 공부하는 것이 얼마나 가치 있을지는 모르겠다. 그럼에도 너무 궁금해서
참을 수가 없다면 언어 명세를 읽어봐도 좋다. 다만, 미로 속에 또 다른 미로를 숨겨 놓은 것 같은
복잡함에 너무 당황하지 않길 바랄 뿐이다.

언어 명세가 복잡하다고 투덜대긴 했지만, 타입 추론의 유용성을 평가 절하하려는 것은 결코 아니
다. 사실은 타입 추론 덕에 C#을 훨씬 쉽게 사용할 수 있게 되었다고 생각한다.

지금까지 살펴봤던 예에서는 타입 매개변수에 어떤 타입이든 지정할 수 있었으며, 동시에 어떤 타
입이든 받아들일 수 있었다. 하지만 이런 방식이 항상 유용하지는 않으므로, 가끔은 타입 매개변

수로 지정할 수 있는 타입의 종류를 제한하고 싶을 수도 있다. 이때 사용할 수 있는 기능이 바로
타입 제약 조건이다.

6 나만 이 부분을 까다롭게 여기고 어려워하는 것은 아니다. 이 책을 쓸 당시 오버로드 해석에 대한 언어 규격에 문제가 있어 C# 5 ECMA 표준
등록에 실패했다. 물론 수정 후 다시 제출할 것이다.

071