Hacker News 의견

• F#에서 차별화된 유니온을 사용해왔고, C#에도 있을 것이라 생각했음

  • Java를 사용 중이며, ADT가 없는 언어로 돌아가는 것이 어렵다고 느끼고 있음
  • C#의 주요 기능 부족을 사과할 필요가 없어져 기쁨

• "타입 유니온"이라는 용어가 생소함

  • ML 계열 언어의 태그 유니온과 유사해 보임
  • C# 개발자들이 기존 용어와 다른 이름을 만드는 경향이 있는지 궁금함

• 오랜 C# 개발자로서 이 제안의 사용 사례가 명확하지 않다고 느낌

  • 빈 인터페이스와 레코드 클래스를 선언하여 구현할 수 있을 것 같음
  • 놓치고 있는 부분이 있는지 궁금함

• TypeScript에는 타입 유니온이 있음

  • F#이나 Haskell의 차별화된 유니온과 유사해 보임
  • 차별화된 유니온에는 명명된 케이스 생성자가 있음

• 패턴 매칭이 가능한 유니온이 없으면 프로그래밍이 어려워짐

  • 표현 문제의 의미를 완전히 이해하지 못했음
  • 기존 다형성을 통한 확장 포인트 제공이 미래의 클라이언트에게 적합할 수 있음
  • 팀이 소유한 코드에는 패턴 매칭이 가능한 유니온이 더 적합함

• C# 유니온에서 필드 오프셋을 사용한 경험이 있음

  • 포인터/참조 값과 값의 별칭이 정의되지 않은 동작을 유발할 수 있음
  • u64와 객체의 구조체 유니온은 별도의 필드를 필요로 하여 8바이트를 낭비할 수 있음

• 비공개 생성자와 nuget 패키지를 사용하여 스위치 타입이 _ 케이스를 필요로 하지 않도록 함

  • 제안된 "유니온 클래스"의 디슈가 버전과 유사함
  • nuget 패키지가 불필요해지고 문법적 설탕이 추가되는 것이 좋음

• 유니온 구조체가 동시 수정 시 찢어짐을 어떻게 처리하는지 언급되지 않음

  • 찢어짐은 메모리 안전 문제를 유발할 수 있음
  • 동일한 오프셋에 정수 필드와 참조 필드를 가진 변형이 있을 수 있음