목록으로
'언젠가 읽기' 컨텐츠는 논문이나 영문 컨텐츠 등 언젠가 읽으려고 즐겨찾기 하고선
읽지 않고 계속 미룰만한 컨텐츠를 읽고 요약하거나 소개합니다.
Go에서 좋은 유니온 타입을 만들려면 아마도 제로 값이 없는 타입이 필요할 것이다
소개
Go 언어에서 유니언 타입(Union Types)을 도입하고자 하는 주요 이유 중 하나는 옵셔널 타입(Option Types)의 일반적인 패턴을 구현하기 위함입니다. 이를 통해 개발자들이 null 값을 명시적으로 처리하도록 강제할 수 있습니다. 그러나 현재 Go의 컴파일러는 이미 사용 전에 null 값 검사를 강제하고 있으며, 유니언 타입과 옵셔널 타입만으로는 null 값을 완전히 방지할 수 없습니다. 이는 개발자들이 결과 값을 제대로 추출하지 않고 제로 값을 반환하는 실수를 할 수 있기 때문입니다.
Union Types와 Option Types의 필요성
옵셔널 타입은 에러가 없는 결과 값을 보장하기 위해 null 값을 명시적으로 처리하도록 합니다. 이는 타입 시스템 내에서 이러한 보장을 표현할 수 있을 때 효과적입니다. 따라서 비null 가능 타입(Non-nullable Types)이 중요하며, 이것이 없다면 모든 개발자가 일정 방식으로 null 값을 확인해야 하거나, 그렇지 않을 경우 null 값이 침투할 위험이 있습니다.
Go에서의 제약 사항
현재 Go는 'null이 될 수 없는 타입'이나 명시적으로 'null'을 표현하는 타입 개념을 제공하지 않습니다. Go의 제로 값(Zero Values) 개념은 nil 포인터와 인터페이스를 포함하여 다양한 타입에서 널리 사용되고 있습니다. 이는 맵, 채널, 슬라이스 등의 제로 값도 특정한 의미를 가지기 때문에, 유니언 타입과 같이 제로 값을 사용하는 타입을 도입하는 것은 복잡성을 더할 수 있습니다.
Non-nullable Types의 중요성
옵셔널 타입의 강력한 기능은 타입 시스템 내에서 그 보장을 표현할 수 있을 때 발휘됩니다. 비null 가능 타입을 도입하면 에러가 없는 결과 값에서 추출된 올바른 값을 보장할 수 있습니다. 하지만 Go는 이러한 타입을 지원하지 않기 때문에, 모든 개발자가 일정 방식으로 null 값을 확인해야 하거나, 제로 값을 사용하는 함수에서 잘못된 값을 반환할 위험이 있습니다.
Zero Values와 Go의 타입 시스템
제로 값은 Go의 타입 시스템 깊숙이 통합되어 있으며, 이는 유니언 타입 도입의 큰 장애물입니다. 유니언 타입을 제로 값을 허용하도록 설계하면 모든 타입 옵션에서 제로 값이 반환될 수 있어, 이는 인터페이스의 nil과 유사한 동작을 하게 됩니다. 이러한 상황에서는 유니언 타입의 도입이 인터페이스 사용의 대안이 되기보다는 메모리 절약 정도의 제한된 이점만을 제공할 뿐입니다.
결론: Go에서의 Union Types 구현 가능성
Go 개발자들이 제로 값의 깊은 통합을 변경할 의지가 없어 보이기 때문에, Go에서 강력한 형태의 유니언 타입을 도입하는 것은 어려울 것으로 예상됩니다. 만약 유니언 타입이 도입된다 하더라도, 이는 주로 메모리 절약을 위한 목적일 가능성이 높으며, Go의 런타임에서 유니언 타입을 다루는 것은 상당한 복잡성을 수반할 것입니다.
참고 자료
-
Union type (Wikipedia)
-
Option type (Wikipedia)
-
Go Issue #57644 논의