decision matrix

clone 제거에서 루프 선택까지 이어지는 판단 흐름

값이 어디서 소유되고, 어떤 변환을 거치며, 어느 지점에서 루프가 더 읽기 쉬운지 단계별로 고릅니다.

1clone 제거

2adapter 연결

3borrow 확인

4loop 선택

clone 제거 Config::build

질문 결과 구조체가 인수 값을 소유해야 하나요?

선택 슬라이스를 빌리지 말고 Iterator를 받아 값을 소비합니다.

impl Iterator<Item = String>

효과 query와 file_path가 복제 없이 Config 안으로 이동합니다.

adapter 연결 search

질문 라인을 거르고 모으는 단순한 변환인가요?

선택 중간 Vec 대신 lines, filter, collect를 이어 붙입니다.

lines().filter(...).collect()

효과 변경 가능한 results 상태보다 검색 의도가 먼저 보입니다.

borrow 안전성 Vec<&str>

질문 반환값이 원본 contents의 일부를 빌리나요?

선택 수명 매개변수로 결과와 원본 텍스트의 관계를 드러냅니다.

fn search<'a>(..., contents: &'a str)

효과 반복자 체인을 써도 빌린 라인이 원본보다 오래 살지 않습니다.

loop 선택 읽기 쉬움

질문 조기 반환, 여러 상태, 복잡한 분기가 핵심인가요?

선택 복잡한 제어 흐름은 루프를, 선형 변환은 반복자를 고릅니다.

효과 성능 추측보다 코드가 말하는 목적을 기준으로 선택합니다.

선택 기준

소유권 이동이 필요하면 반복자를 소비하고, 빌린 조각을 반환하면 수명을 확인하며, 변환 흐름이 단순할수록 어댑터 체인이 잘 맞습니다.