나도 그 생각을 했지만, 결국 피할 수 없는 변경을 미루면 문제가 더 커질 뿐이라고 봄
실제로 큰 문제는 아닐 듯한데, Zig 저장소의 수천 개 @bitCast 중 이 변경의 영향을 받은 건 100개보다 훨씬 적었던 것 같음
솔직히 배열/벡터와 스칼라 사이 변환에서 @bitCast가 어떻게 동작하는지 대부분의 Zig 사용자가 정확히 알고 있었다고도 생각하지 않음. 기존에는 작성자 시스템에서만 테스트되어 리틀엔디언에서만 동작하던 코드가 이제는 어디서나 동작하게 되는 경우도 많을 듯함

예전 C 프로그래머로서, C의 비트 필드는 아키텍처마다 동작이 이식 가능하지 않아 별로 인기가 없었던 걸로 기억함
새 Zig @bitCast 의미론은 서로 다른 아키텍처에서도 같은 결과를 주는 이식 가능한 추상 의미론이라서 딱 필요했던 방향이라고 봄
최근 내 언어의 비트 필드와 비트 캐스트 설계를 하고 있어서, 내 코드가 어떻게 동작해야 할지 명확히 하려고 Zig 설계와 구현 문서를 더 자세히 볼 생각임

C 비트 필드에 대한 Zig의 주된 대안은 아마 packed struct 와 packed union 이고, 둘 다 새 @bitCast 정의와 잘 맞도록 정의되어 있음 packed struct는 필드의 비트를 “기반 정수”에 채워 넣는 방식임. 예를 들어 필드가 bool, u6, i9이고 기반 정수가 u16이면, u16의 최하위 비트가 bool, 다음 6비트가 u6, 나머지 9비트가 i9가 됨. 즉 Zig의 packed struct는 여러 시프트와 마스크 위에 얹힌 문법 설탕에 가까움 packed union도 기반 정수를 가지지만, 모든 필드가 기반 정수와 정확히 같은 비트 수를 써야 함. 그래서 한 필드에 저장하고 다른 필드에서 읽는 동작은 새 의미론의 @bitCast와 거의 동일함. 다만 packed union/packed struct 필드는 배열이나 벡터 타입을 가질 수 없음
개인적으로는 이런 도구들이 “비트 관련 구조”를 표현하기에 잘 맞는다고 봄. 여러 값을 packed struct로 비트 패킹해 C 비트 필드처럼 쓸 수 있고, 비트 연산 위의 문법 설탕이라 C에서 타입 안전하지 않은 매크로 더미로 처리하던 비트 플래그도 깔끔하게 표현 가능함
예를 들어 RWX 접근 플래그는 C에서는 ACCESS_READ, ACCESS_WRITE, ACCESS_EXEC 매크로와 uint8_t API로 받을 수 있지만, Zig에서는 Access = packed struct(u8)로 read, write, exec, reserved 필드를 정의하고 API에서 Access를 받을 수 있음 packed struct와 packed union을 쓰면 꽤 이상한 비트 배치도 표현할 수 있음. Mach-O 객체 포맷의 심볼 테이블 엔트리에는 역사적 이유로 보이는 특이한 n_type 필드가 있는데, 이를 packed union(u8) 안에 bits: packed struct(u8)와 stab: enum(u8) 형태로 모델링할 수 있음
이 n_type 값을 다룰 때 수동 시프트나 마스킹이 필요 없음. n_type.bits.is_stab != 0을 확인하고 참이면 n_type.stab으로 switch하면 되고, 아니면 n_type.bits의 다른 필드를 보면 됨. 반대로 .{ .stab = .gsym }나 .{ .bits = .{ .ext = false, .type = .undf, .pext = false, .is_stab = 0 } }처럼 값을 만들 수도 있음
원 글 주제와는 다른 언어 기능으로 조금 길어졌지만, 새 언어 설계에 참고할 만한 걸 찾는다면 Zig의 packed struct와 packed union을 직접 써보면 좋겠음. 단순하지만 꽤 괜찮은 도구라고 봄