fix: scope

_posts/2024-10-05-Access-level modifiers-on import-declarations.md

@@ -168,8 +168,9 @@ public import 구조체 Foo.Bar
 이 제안은 특정한 의미를 부여하지 않기 때문에 `open`이라는 액세스 수준 수정자를 import에 계속 사용할 수 있습니다. 이를 공식 `@_exported`로 사용하는 것이 제안되었습니다. 즉, 모듈의 모든 소스 파일에서 볼 수 있고 클라이언트에게 동일한 모듈의 일부인 것처럼 표시되는 import를 표시하는 것입니다. 일반적으로 `@_exported`를 사용하여 두 모듈이 같은 이름을 공유하는 모듈을 클랭할 때 을 사용하는데, 두 모듈이 같은 이름을 공유하며 클라이언트에게 통합된 것으로 표시하려는 의도가 있습니다.
 
 이 제안에 이 변경 사항을 포함시키지 않은 이유는 크게 두 가지입니다:
-  1. `open`으로 표시된 선언은 모듈 외부에서 재정의할 수 있습니다. 이 의미는 `@_exported`의 동작과 관련이 없습니다. 다른 액세스 수준은 선언과 가져오기 선언에서 사용할 때 상응하는 의미를 갖습니다.
-  2. 이 제안의 동기는 구현 세부 사항을 숨기고 의존성 크리프를 제한하기 위해서입니다. `open import` 또는 `@_exported`의 사용을 장려하는 것은 이러한 동기에 반하며 다른 문제를 해결합니다. 관련 동기를 가진 별도의 제안서에서 논의되어야 합니다.
+1. `open`으로 표시된 선언은 모듈 외부에서 재정의할 수 있습니다. 이 의미는 `@_exported`의 동작과 관련이 없습니다. 다른 액세스 수준은 선언과 가져오기 선언에서 사용할 때 상응하는 의미를 갖습니다.
+2. 이 제안의 동기는 구현 세부 사항을 숨기고 의존성 크리프를 제한하기 위해서입니다. `open import` 또는 `@_exported`의 사용을 장려하는 것은 이러한 동기에 반하며 다른 문제를 해결합니다. 관련 동기를 가진 별도의 제안서에서 논의되어야 합니다.
+
 ### API에서의 사용으로부터 의존성의 가시성 추론하기
 컴파일러는 모듈을 분석하여 public 선언에서 사용되며 클라이언트에게 표시되어야 하는 종속성을 결정할 수 있습니다. 그런 다음 다른 모든 종속성을 자동으로 내부 종속성으로 간주하고 다른 기준을 충족하면 간접 클라이언트에서 숨길 수 있습니다.