이 큐에 개수를 캐시하는 필드가 필요할까요?

질문 자체부터 드러내 보면 어떨까요? exceedsLimit queue limit로 두고, 한도는 음수가 아니어야 한다고 정해요. 호출하는 쪽은 딱 필요한 답을 얻고, 큐는 계속 맞춰 둬야 할 두 번째 구성 요소를 갖지 않아도 돼요. 이 표현에서는 안쪽에서 List.compare_length_with가 일을 해 줘요.

호출하는 쪽이 작업을 받을지 정하는 자리라면 결과에 WithinLimit와 OverLimit라는 이름을 붙여 분기를 읽기 쉽게 할 수도 있어요. 주변의 if가 이미 구분을 설명하고 있다면 그냥 불리언이어도 괜찮아요. 비교 하나를 감싸려고 케이스를 늘릴 필요는 없어요.

정확한 개수가 다른 곳에서 쓸모 있어지면 캐시는 그때 넣으면 돼요. 그때는 생성과 갱신을 같은 인터페이스 뒤에 두어서, 어떤 호출자도 items나 count를 혼자 바꿔 끼우지 못하게 하고요. 지금은 이 정도면 충분하겠네요.

OverLimit는 생산자에게 멈추라고 할 뿐이에요. 그다음은요? 생산자가 거기서 막힌다면 그 수를 세어 봐야 해요. 가득 찬 채널에서 멈춘 고루틴은 싸지만, 거기 몇 개까지 쌓일 수 있는지는 아무것도 막지 않아요. 큐의 한도는 대기열을 아무도 재지 않는 곳으로 옮길 뿐이에요.

그 인터페이스를 .mli에 두고 type t는 정의 없이 선언만 하십시오. 그러면 모듈 밖 어디에서도 그 쌍을 손으로 만들 수 없고, 나중에 개수를 추가해도 바뀌는 파일은 하나, 불변식이 깨질 수 있는 곳도 정확히 한 군데입니다.

뭘 따로 추가하지 않으면 아무것도 없어. Kotlin에서 용량이 정해진 Channel은 꽉 차면 send를 중단시키는데, 중단된 송신자도 각자 잡은 걸 다 들고 있는 살아 있는 코루틴이야. 그 수는 그냥 띄운 만큼이고. 띄우는 쪽을 제한하든가, 앞에 Semaphore를 둬.