이와 같은 접근 전략을 취하면, 매개변수가 예기치 않게 변경되는 것을 사전에 차단할 수 있다. 모든 메서드가 private이므로 메서드 수행 중에 값이 변경될 가능성이 있는지를 모조리 검사할 수 있기 때문이다. 앞의 예제를 살펴보면 PublicMethod를 호출할 때에 각 구조체의 복사본이 한 벌씩 생성되기는 하지만, 이후 수행하는 private 메서드에서는 추가적인 복사본이 생성되지 않고 동일한 저장소 공간에 대한 별칭만이 부여된다. 즉, 최초 호출자의 코드가 다른 스레드에서 수행되거나, 혹은 다른 외부 메서드로 인해 공개된 API에 전달했던 매개변수의 값이 변경되더라도 내부 코드는 이러한 변경으로부터 철저하게 격리될 수 있다. 가끔은 매개변수의 값을 변경하고 싶을 수도 있을 것이다. 이런 경우라면 면밀하게 문서화를 하고 조심스럽게 관리해야 한다.
내부적으로 사용하는 메서드를 호출할 때도 동일한 방법을 사용할 수 있다. 이 또한 충분히 합리적이라고 평가할 수는 있지만, 대체로 호출되는 코드의 내용이 많을 것이므로 충분한 검토가 필요하다. 개인적인 취향일 수 있지만, 내 경우에는 메서드 내부에서 무슨 일이 일어나는지를 손쉽게 이해할 수 있도록 매개변수를 선언할 때뿐만 아니라 메서드를 호출할 때도 반드시 in 한정자를 명시적으로 사용한다.
지금까지 살펴봤던 내용들을 간략하게 정리해 봤다.
• 성능 측정 결과, 명백한 성능 개선이 예상되는 경우에만 in 매개변수를 사용하라. 크기가 큰 구조체를 사용하는 경우라면 대부분의 경우 in 매개변수가 도움이 될 것이다.
• 매개변수의 값이 변경되더라도 메서드 수행에 전혀 영향이 없는 경우가 아니라면, 공개 API에서는 in 매개변수를 사용하지 말라.
• public 메서드를 매개변수의 변경에 대한 경계로 삼고, private 메서드 간에는 매개변수에 대한 복사가 일어나지 않게 in 매개변수를 사용하는 것을 고려해 보라.
• 컴파일러가 보이지 않는 지역 변수를 내부적으로 생성하고 이에 대한 참조를 전달하는 등의 기능이 반드시 필요한 경우가 아니라면, 메서드 호출 시에도 in 한정자를 명시적으로 사용하는 것을 검토해 보라.