같은 Int, 두 타깃, 두 개의 답

리터럴은 찾기 쉬운 경우입니다. 각각 안전 범위 한가운데 있는 정수 두 개를 곱해도 곱은 런타임에 2^53을 넘을 수 있습니다. JS 타깃은 제일 가까운 double로 반올림하고 반환합니다. Erlang 타깃은 더 큰 정수를 할당하고 반환합니다. 어느 분기도 아무것도 보고하지 않으므로, 알아챌 수 있는 것은 JavaScript에서 도는 테스트뿐입니다. 패키지가 두 타깃을 모두 지원한다고 한다면 기본 실행 옆에 gleam test --target javascript가 있어야 하고, 테스트에는 작은 값이 아니라 한계를 넘는 값이 들어가야 합니다.

타깃별로 다르게 하는 부분은, Gleam에서 함수 하나에 한 타깃용 external과 나머지 타깃용 Gleam 본문을 같이 둘 수 있어요. 맞는 external이 없는 곳에서는 본문이 실행돼요.

@external(javascript, "./int_ffi.mjs", "is_safe")
pub fn is_safe(_n: Int) -> Bool {
  True
}

export function is_safe(n) {
  return Number.isSafeInteger(n);
}

Erlang에서는 본문이 True를 돌려주는데, 거기서는 잃는 게 없으니 맞는 답이에요. JavaScript에서는 Number.isSafeInteger가 실제 숫자를 받아요. 이미 반올림된 값도 잡아내요. 한계를 넘은 값이 반올림으로 다시 안전 범위 안에 들어오는 일은 없거든요. 묻는 내용이 런타임에 관한 것이니 답이 그 런타임 쪽 파일에 있는 게 자연스러워요.

잘 됐어요. 아무도 검사를 건너뛸 수 없게 이제 opaque 타입 뒤에 있어요. pub opaque type Id에 is_safe가 아니라고 하면 Error(Nil)을 돌려주는 from_int를 붙였어요. 이제 JavaScript에서 id용 JSON 디코더는 반올림된 이웃 값을 내주지 않고 거절하고, Erlang은 오류 분기에 한 번도 안 들어가요. 딱 맞는 동작이에요.