부분 순서 기반 연산자 우선순위

Zig master 브랜치가 일부 연산자 조합의 우선순위를 없애고, 괄호로 평가 순서를 명시하도록 요구함 x orelse y == z처럼 혼동하기 쉬운 조합은 컴파일 오류가 되지만, x + y * z 같은 일반적인 산술식은 괄호 없이 사용할 수 있음 목표는 개발자가 외워야 할 우선순위 규칙을 줄이는 것이며, Zig 코드베이스에서는 100만 줄 이상 중 353줄만 수정이 필요했음 기존 코드는 컴파일 오류를 하나씩 수정하거나 zig fmt --upgrade 로 이전 평가 순서를 유지하는 괄호를 자동 추가할 수 있음 자동 변환은 기존 동작을 보존하지만 개발자의 의도까지 검증하지는 않음. 수동 검토 과정에서 우선순위를 잘못 이해해 생긴 버그를 발견할 수 있음 일부 연산자 조합에 괄호 요구 2016년 2월 8일 등록된 제안 #114가 약 10년 만에 Zig master 브랜치에 구현됨 구현 직전까지 열려 있는 Zig 언어 제안 중 두 번째로 오래된 제안이었음 이제 일부 연산자 조합에는 정의된 우선순위가 없으며, 컴파일러가 괄호를 요구함 const a = x orelse y == z;는 ambiguous operator precedence 오류를 발생시킴 진단 메시지는 모호한 두 연산자의 위치와 함께, Zig 0.17.x에서는 (... orelse ...) == ... 순서로 평가됐다는 정보도 제공함 반면 익숙한 산술 우선순위는 유지되므로 const a = x + y * z;에는 괄호가 필요하지 않음 외워야 할 규칙을 줄이는 설계 복잡한 연산자 조합의 평가 순서를 기억하거나 찾아보게 하는 대신, 코드 자체에 괄호로 순서를 드러내는 것이 목적임 다음 식은 기존 규칙을 모르면 평가 순서를 파악하기 어려움 a & b + c * d >> e | f orelse g() catch h + i == j or k and l Zig 0.17.x의 평가 순서를 유지하면서 필요한 괄호를 추가하면 다음과 같음 ((((a & ((b + c * d) >> e)) | f) orelse g()) catch (h + i)) == j or (k and l); 여전히 복잡하지만, 산술과 비교 이외의 우선순위 규칙을 몰라도 구조를 이해할 수 있음 실제로 새 괄호가 필요한 식은 비교적 드물었으며, Zig 코드베이스 100만 줄 이상에서 353줄이 변경됨 유지되는 우선순위와 나머지 연산의 예외 산술 연산이 포함된 코드를 읽고...