관련 문제:
https://github.com/rust-lang/rust/issues/25477
https://github.com/rust-lang/rust/pull/34265

아마도 이것은 부엌 싱크대를 포함할 필요가 없지만 범위 매개변수를 _할 수_ 있으므로 배수관의 상위 집합과 같습니다. 그것에 대한 단점이 있습니까? 범위를 확인하는 경계를 추가하는 것이 단점이라고 생각합니다. 당황할 수 있는 또 다른 문제입니다. 그러나 drain_filter(.., f)는 할 수 없습니다.

머지 않은 미래에 이것이 어떤 형태로든 안정화될 가능성이 있습니까?

컴파일러가 경계 검사를 제거할 만큼 똑똑하다면
drain_filter(.., f) 경우 이 작업을 선택합니다.

(그리고 나는 당신이 그것을 어떤 방식으로 구현할 수 있다고 확신합니다.
최악의 경우 컴파일러를 충분히 영리하게 만듭니다.
"기능 내 전문화"가 있을 수 있는 경우
기본적으로 if Type::of::<R>() == Type::of::<RangeFull>() { dont;do;type;checks; return } 와 같은 것)

이것이 어느 정도 자전거 이동이라는 것을 알고 있지만 drain_where drain_filter 이름을 지은 이유는 무엇입니까? 나에게 전자는 전체 Vec 가 소진되지만 결과에 대해 filter 도 실행한다는 것을 의미합니다. .drain(..).filter() ?"). 반면에 전자는 어떤 조건이 유지되는 경우에만 요소를 배출한다는 것을 나타냅니다.

잘 모르겠지만 drain_where 가 훨씬 더 잘 들리고 훨씬 더 직관적입니다.
아직 변경할 기회가 있습니까?

.remove_if 도 이전 제안이었습니다.

drain_where 가 가장 잘 설명된다고 생각합니다. 배수와 마찬가지로 값을 반환하지만 모든 값을 배수/제거하지는 않지만 주어진 조건이 참인 경우에만 해당합니다.

remove_if 는 조건이 참인 경우 인덱스별로 단일 항목을 제거하는 remove 의 조건부 버전과 매우 유사합니다. 예를 들어 letters.remove_if(3, |n| n < 10); 는 <10인 경우 인덱스 3의 문자를 제거합니다. .

반면에 drain_filter 는 약간 모호합니다. drain 다음 filter 를 더 최적화된 방식으로(예: filter_map) 또는 반복자가 다음과 비교할 수 있도록 반환되도록 배수합니다. 반복자 filter 는 반환할 것이고,
필터가 이전에 논리적으로 사용되기 때문에 filtered_drain 라고 해서는 안 됩니다.

표준 라이브러리 어디에서나 _where 또는 _if 를 사용한 선례는 없습니다.

@Gankro 어디에서나 _filter 를 사용한 선례가 있나요? 나는 그것이 덜 모호한 용어를 사용하지 않는 이유인지도 모릅니다. 표준 라이브러리의 다른 곳에서는 이미 _until 및 _while 와 같은 다양한 접미사를 사용하고 있습니다.

주석의 "동등한" 코드가 올바르지 않습니다... "여기에 있는 코드" 사이트에서 i에서 1을 빼야 합니다. 그렇지 않으면 나쁜 일이 발생합니다.

IMO 문제는 filter 가 아닙니다. 방금 이것을 검색한(그리고 초보자) drain 는 다른 언어에 비해 상당히 비표준적인 것 같습니다.

다시 말하지만, 초보자의 관점에서 이 문제가 제안하는 작업을 수행하려고 할 때 검색할 항목은 delete ( delete_if 에서와 같이 ), remove 입니다. , filter 또는 reject .

나는 실제로 filter $ 를 _검색_ 하고 drain_filter 를 보았고 drain 가 내가 하고 싶은 간단한 것을 나타내지 않는 것 같았기 때문에 읽지 않고 _계속 검색_했습니다.

filter 또는 reject 라는 간단한 함수가 훨씬 더 직관적일 것 같습니다.

별도의 메모에서, 이것이 호출되는 벡터를 변경해야 하는 것처럼 느껴지지 않습니다. 체이닝을 방지합니다. 이상적인 시나리오에서는 다음과 같은 작업을 수행할 수 있기를 원할 것입니다.

        vec![
            "",
            "something",
            a_variable,
            function_call(),
            "etc",
        ]
            .reject(|i| { i.is_empty() })
            .join("/")

현재 구현에서 결합할 대상은 거부된 값입니다.

accept 및 reject 둘 다 보고 싶습니다. 어느 쪽도 원래 값을 변경하지 않습니다.

filter 만으로도 이미 연결 작업을 수행할 수 있습니다. drain_filter 의 요점은 벡터를 변경하는 것입니다.

@rpjohnst 그래서 여기 에서 검색했는데 filter 어딘가에 누락 되었습니까?

예, Vec 가 아닌 $ Iterator 의 구성원입니다.

Drain은 컨테이너에만 적용되는 Rust의 네 번째 소유권을 나타내기 때문에 새로운 용어입니다. 또한 일반적으로 거의 모든 다른 언어에서는 의미가 없습니다(이동 의미 체계가 없으면 단일 ""원자"" 작업).

drain_filter는 배수 용어를 다른 언어가 신경 쓸 공간으로 이동하지만(백시프트를 피하는 것은 모든 언어에서 관련이 있기 때문에).

$ rust consume vec 에 대한 Google 결과로 문서에서 drain_filter 을(를) 발견했습니다. 나는 기본적으로 녹의 불변성으로 인해 필터가 데이터를 소비하지 않는다는 것을 알고 있습니다. 메모리를 더 잘 관리할 수 있도록 접근 방법을 기억할 수 없었습니다.

drain_where 도 좋지만 사용자가 drain 및 filter 가 무엇을 하는지 알고 있는 한 이 메서드가 술어 필터를 기반으로 데이터를 드레인하는 것이 분명하다고 생각합니다.

나는 여전히 drain_filter 가 배수(즉, 비움)한 다음 필터링한다는 것을 의미하는 것처럼 느낍니다. 반면에 drain_where 는 주어진 조건이 유지되는 요소를 배수하는 것처럼 들립니다(제안된 기능이 수행하는 작업).

술어와 일치하는 나머지 요소를 제거하기 위해 linked_list::DrainFilter 도 Drop $를 구현해야 하지 않습니까?

네

반복자를 삭제하면 왜 반복자가 끝까지 실행됩니까? iterator에 대한 놀라운 동작이라고 생각하며 원하는 경우 명시적으로 수행할 수도 있습니다. 반면에 반복자를 mem::forget 하면 누출 증폭이 발생하기 때문에 필요한 만큼만 요소를 제거하는 역은 불가능합니다.

저는 이 기능을 많이 사용해 왔으며 항상 배수하려는 항목에 대해 true 를 반환해야 한다는 것을 기억해야 합니다. 이는 retain() / retain_mut() 에 비해 직관적이지 않습니다.
직관적인 논리적 수준에서 내가 유지하고 싶은 항목에 대해 true 를 반환하는 것이 더 합리적일 것입니다. 다른 사람도 이런 생각을 합니까? (특히 retain() 가 이미 이런 식으로 작동한다는 점을 고려하면)
그렇게 하지 않고 drain_filter() 의 이름을 retain_iter() 또는 retain_drain() (또는 drain_retain() )로 바꾸십시오.
그러면 retain() 도 더 가깝게 미러링됩니다!

이것이 내가 이름을 다음으로 바꾸자고 제안한 이유입니다
drain_where 다음과 같이 명확합니다.

1. 배수구의 한 형태이므로 이름에 배수구를 사용합니다.

2. where 를 drain 와 함께 사용하면
   요소 _where_ 술어가 true이면 배수됩니다. 즉, 제거되고 반환됩니다.

3. 일반적으로 다음이 있는 경우 std의 다른 이름과 더 동기화됩니다.
   두 개의 술어로 구성된 함수는 다음을 사용하여 (대략) 에뮬레이트할 수 있습니다.
   "and then" 방식으로 각 술어를 나타내는 함수, 예
   filter_map 는 (대략) filter an then map 로 에뮬레이트될 수 있습니다. 현재
   name 은 drain and then filter 임을 나타내지만 그 근처에도 없습니다.
   완전히 배수를 하지 않기 때문입니다.

2018년 2월 25일 일요일 17:04 Boscop [email protected] 에서 다음과 같이 썼습니다.

나는 이 기능을 많이 사용해왔고 항상 기억해야 한다.
내가 배수하려는 항목에 대해 true를 반환합니다.
Retain_mut()에 비해 직관적이지 않습니다.
원시 수준에서는 I 항목에 대해 true를 반환하는 것이 더 합리적입니다.
유지하고 싶어, 다른 사람이 이런 식으로 느끼나요?
왜 그렇게 하지 않고 drain_filter()의 이름을retain_filter()로 바꾸나요?

—
이 스레드에 가입했기 때문에 이 메시지를 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/rust-lang/rust/issues/43244#issuecomment-368320990 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AHR0kfwaNvz8YBwCE4BxDkeHgGxLvcWxks5tYYRxgaJpZM4OY1me
.

그러나 drain_where() 를 사용하면 클로저가 제거해야 하는 요소에 대해 여전히 true를 반환해야 하며 이는 retain() 의 반대이므로 일관성이 없습니다.
아마도 retain_where ?
하지만 이름에 "드레인"을 포함하는 것이 맞다고 생각합니다. 그래서 drain_retain() 가 가장 의미가 있다고 생각합니다. drain() 와 비슷하지만 클로저가 반환되는 요소를 유지합니다. true .

변경되지는 않지만 true를 반환해야 한다는 것은
당신은 그렇게해야합니다.

개인적으로 다음 중 하나를 사용합니다.

ㅏ. drain_where
비. retain_where
씨. retain

나는 drain_retain 를 사용하지 않을 것입니다.
배수 및 유지는 같은 종류의 프로세스에 대해 이야기하지만 반대입니다.
관점, 배수는 당신이 제거(및 r 반환) 유지에 대해 말합니다.
당신이 유지하는 것에 대해 이야기합니다 (이미 std에서 사용되는 방식으로).

현재 retaim 는 이미 std로 구현되어 있으며 주요 차이점이 있습니다.
drain 가 요소를 반환하는 동안 요소를 버리므로
retain (슬프게도) 이름에 사용하기에 부적합합니다(전화를 하려는 경우 제외
retain_and_return 또는 이와 유사한 것).

배수에 대해 말하는 또 다른 요점은 마이그레이션의 용이성입니다.
drain_where 로 변경하는 것은 단어 기반 검색을 실행하는 것만큼 쉽습니다.
코드를 유지하도록 변경하는 동안 추가 부정이 필요합니다.
사용된 모든 술어/필터 기능.

2018년 2월 25일 일요일 18:01 Boscop [email protected] 에서 다음과 같이 썼습니다.

그러나 drain_where()를 사용하면 클로저가 여전히 true를 반환해야 합니다.
제거해야 하는 요소, 이는 유지()의 반대입니다.
모순되게 만든다..
아마도 keep_where?
하지만 이름에 "드레인"을 포함하는 것이 의미가 있다고 생각합니다.
그래서 저는 drain_retain()이 가장 의미가 있다고 생각합니다. 그것은 drain()과 비슷하지만
클로저가 true를 반환하는 요소를 유지합니다.

—
이 스레드에 가입했기 때문에 이 메시지를 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/rust-lang/rust/issues/43244#issuecomment-368325374 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AHR0kfG4oZHxGfpOSK8DjXW3_2O1Eo3Rks5tYZHxgaJpZM4OY1me
.

하지만 drain() 에서 drain_filter() 로 얼마나 자주 마이그레이션하시겠습니까?
지금까지의 모든 경우에 std에 retain_mut() 가 없고 요소를 변경해야 하기 때문에 retain() 에서 drain_filter() 로 마이그레이션했습니다! 그래서 클로저 반환 값을 반전시켜야 했습니다.
drain_retain() 는 drain() 메서드가 범위의 모든 요소를 ​​무조건 배출하는 반면 drain_retain() 는 클로저가 true 를 반환하는 요소를 유지하기 때문에 의미가 있다고 생각합니다. drain() 및 retain() 방법의 효과.

죄송합니다 drain_filter 에서 drain_where 로 마이그레이션하려고 합니다.

retain 를 사용하는 솔루션이 있고 다음을 사용해야 합니다.
drain_filter 는 아직 고려하지 않은 측면입니다.

2018년 2월 25일 일요일 19:12 Boscop [email protected] 에서 다음과 같이 썼습니다.

하지만 왜 drain()에서 drain_filter()로 마이그레이션합니까?
지금까지의 모든 경우에 나는 유지()에서 배수 필터()로 마이그레이션했습니다.
std에는 유지_mut()이 없고 요소를 변경해야 하기 때문입니다!
나는 drain() 메서드가 배수되기 때문에 drain_retain() 이 의미가 있다고 생각합니다.
범위의 모든 요소를 ​​무조건적으로 유지하는 반면, drain_retain()은
클로저가 true를 반환하는 요소.

—
이 스레드에 가입했기 때문에 이 메시지를 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/rust-lang/rust/issues/43244#issuecomment-368330896 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AHR0kSayIk_fbp5M0RsZW5pYs3hDICQIks5tYaJ0gaJpZM4OY1me
.

아 예, 하지만 drain_filter() 를 사용하는 현재 코드에서 클로저를 반전시키는 "가격"은 그만한 가치가 있다고 생각합니다. std에서 일관되고 직관적인 API를 얻은 다음 안정적으로 얻을 수 있습니다.
그것은 단지 작은 고정 비용입니다(그리고 함수의 이름을 바꾸는 것과 함께 진행된다는 사실에 의해 완화되므로 컴파일러 오류는 사용자에게 클로저가 반전되어야 함을 알려서 조용히 버그를 도입하지 않도록 할 수 있습니다) , drain_filter() 표준화 비용과 비교하면 사람들은 retain() 에서 drain_filter() 로 마이그레이션할 때 항상 클로저를 반전시켜야 합니다. 그렇게 하고 retain() 에서 " retain() 와 비슷하지만 &mut 를 클로저에 전달하여 문서에서 찾기 어렵게 만드는 비용 이것이 이 함수의 새 이름에 이름에 "retain"이 포함되어 사람들이 문서에서 검색할 때 찾을 수 있도록 하는 것이 합리적이라고 생각하는 이유입니다.

일부 일화 데이터: 내 코드에서는 항상 drain_filter() 의 retain_mut() 측면만 필요했습니다(이전에는 retain() 를 사용하는 경우가 많음). 배수된 값을 처리합니다. 나는 이것이 미래에 다른 사람들 &mut 가장 일반적인 사용 drain_filter() 가 될 것이라고 생각합니다 retain() , 너무, 그리고 배수된 값을 처리해야 하는 것보다 더 일반적인 사용 사례입니다.

내가 drain_retain 에 반대하는 이유는 현재 std wrt에서 이름이 사용되는 방식 때문입니다. 컬렉션:

1. 관련된 생산/소비 개념이 있는 술어를 사용하는 함수 이름이 있습니다(wrt. rust, iterations). 예를 들어 drain , collect , fold , all , take , ...
2. 이 술어에는 *_where , *_while 와 같은 수정자가 있습니다.
3. 수정 속성이 있는 술어를 사용하는 함수 이름이 있습니다( map , filter , skip , ...)
   
   
   
   • 요소 또는 반복 수정인지 모호합니다( map 대 filter / skip ).
   
   
4. 속성 수정을 사용하여 여러 술어를 연결하는 함수 이름(예: filter_map
   
   
   
   • 대략 apply modifier_1 and then apply modifier_2 의 개념을 가지고 있습니다. 한 번에 이 작업을 수행하는 것이 더 빠르고 유연합니다.
   
   

다음과 같은 경우가 있습니다.

1. 생성/소비 술어와 수정 술어를 결합한 함수 이름(예: drain_filter )
   
   
   
   • _하지만_ 대부분의 경우 수정자와 결합하는 것이 더 낫거나 덜 혼란스럽습니다(예: drain_where ).
   
   

당신은 일반적으로 가지고 있지 않습니다:

1. 생성/소비 술어 중 두 가지가 하나의 이름으로 결합됩니다. 즉, 쉽게 혼동되기 때문에 take_collect 와 같은 생각이 없습니다.

drain_retain 은 다소 의미가 있지만 마지막 범주에 속하지만 기본적으로 remove and return all elements "somehow specified" and then keep all elements "somehow specified" discarding other elements 라고 말하는 것이 무엇인지 추측할 수 있습니다.

다른 한편으로는 modify + retain 를 결합하는 효율적인 방법으로 retain_mut 를 소개하는 빠른 RFC를 여는 retain_mut 가 없어야 하는 이유를 모르겠습니다. retain 더 빠를 수도 있습니다.
이 기능이 안정화되었습니다. 그때까지는 다음을 제공하는 확장 특성을 작성하는 것을 고려할 수 있습니다.
iter_mut + bool-array(또는 bitarray 또는...)를 사용하여 $ retain_mut 를 소유하여 어떤 요소를 추적하는지
제거해야 합니다. 또는 내부적으로 drain_filer / drain_where 를 사용하는 자체 drain_retain $ 제공
그러나 술어를 not |ele| !predicate(ele) 로 래핑합니다.

@dathinab

1. 여기서는 Iterator가 아닌 컬렉션에 대한 방법에 대해 이야기하고 있습니다. map, filter, filter_map, skip, take_while 등은 모두 Iterator의 메소드입니다. Btw, *_where 를 사용한다는 것은 어떤 방법을 의미합니까?
   그래서 우리는 retain() , drain() 와 같이 컬렉션에 이미 존재하는 메소드와 명명 체계를 비교해야 합니다. 하나의 반복자를 다른 반복자로 변환하는 Iterator 메서드에는 혼동이 없습니다.
2. AFAIK 합의는 drain_filter() retain_mut() 가 std에 추가되지 않을 것이라는 것이었습니다. retain() 에서 drain_filter() 로 마이그레이션하는 사용 사례는 매우 일반적이므로 유사한 이름과 API를 가져야 합니다( true 를 반환하는 클로저는 항목을 유지한다는 의미입니다. )..

retain_mut 이(가) 이미 논의되었다는 사실을 몰랐습니다.

우리는 std의 일반적인 명명 체계에 대해 주로 wrt에 대해 이야기하고 있습니다. 에게
Iterators는 주요 컬렉션 중 하나이므로 Iterator를 포함합니다.
녹에 있는 컬렉션에 대한 액세스 방법, 특히 다음과 같은 경우
둘 이상의 항목을 수정합니다.

• _where 는 약간 수정된 것을 표현하기 위한 접미사의 예일 뿐입니다.
  기능. 현재 표준에서 사용되는 이러한 종류의 접미사는 주로
  _until , _while , _then , _else , _mut 및 _back .

drain_retain 이 혼란스러운 이유는 그것이 맞는지 명확하지 않기 때문입니다.
배수 또는 유지 기반, 배수 기반인 경우 true를 반환하면 제거됩니다.
값이 유지 기반인 경우 유지합니다. _where 를 사용하면
마지막으로 전달된 함수에 대해 예상되는 내용을 지웁니다.

2018년 2월 26일 월요일 00:25 Boscop [email protected] 에서 다음과 같이 썼습니다.

@dathinab https://github.com/dathinab

1. 여기서는 Iterator가 아닌 컬렉션에 대한 방법에 대해 이야기하고 있습니다.
   map, filter, filter_map, skip, take_while 등은 모두 Iterator의 메소드입니다.
   Btw, *_where를 사용한다는 것은 어떤 방법을 의미합니까?
   따라서 우리는 명명 체계를 이미 존재하는 메서드와 비교해야 합니다.
   컬렉션에 대해, 예를 들어 유지(), 배수(). 와 혼동이 없다.
   반복자를 다른 반복자로 변환하는 반복자 메서드.
2. AFAIK 합의는 stay_mut()이 std에 추가되지 않을 것이라는 것이었습니다.
   drain_filter()가 이미 추가되고 사람들이 조언을 받았기 때문에
   그것을 사용합니다. 다음에서 마이그레이션의 사용 사례로 돌아가
   Retain() to drain_filter()는 매우 일반적이므로 다음을 가져야 합니다.
   유사한 이름 및 API(true를 반환하는 클로저는 항목을 유지함을 의미함)..

—
당신이 언급되었기 때문에 이것을 받는 것입니다.

이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/rust-lang/rust/issues/43244#issuecomment-368355110 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AHR0kfkRAZ5OtLFZ-SciAmjHDEXdgp-0ks5tYevegaJpZM4OY1me
.

저는 이 함수를 많이 사용해 왔고 항상 비우고 싶은 항목에 대해 true를 반환해야 한다는 것을 기억해야 합니다. 이는 유지()/retain_mut()에 비해 직관적이지 않습니다.

FWIW, 여기서 retain 는 직관적이지 않은 이름이라고 생각합니다. 나는 보통 벡터에서 특정 요소를 삭제 하고 싶어하며 retain 를 사용하여 항상 해당 논리를 반전시켜야 합니다.

근데 retain() 는 이미 스테이블이 있어서 같이 살아야지.. 그래서 내 직감이 익숙해졌어..

@Boscop : retain drain 도 마찬가지지만 제거된 요소와 _until , _while 와 같은 접미사 사용을 반환합니다. 기존 기능의 약간 수정된 버전인 사용 가능한 기능.

배수를 설명하면 다음과 같습니다.

_"어떤 방식으로든" 지정된 모든 요소를 ​​제거하고 반환하고 다른 모든 요소는 유지_
여기서 _"어떤 식으로든"_은 슬라이스 가능한 모든 컬렉션 유형에 대해 _"슬라이싱에 의한"_이고 나머지 유형에 대해서는 _"모두"_입니다.

여기서 논의된 기능에 대한 설명은 다음을 제외하고는 _동일합니다_
_"어떤 식으로든"_는 _"이며, 여기서 주어진 술어는 true를 반환합니다."_.

다른 한편으로는 내가 유지하고자 하는 설명은 다음과 같습니다.
_주어진 술어가 true를 반환하는 요소만 유지(즉 유지)하고 나머지는 버립니다_

(예, 유지는 나머지를 버리지 않는 방식으로 사용될 수 있었지만 슬프게도 그렇지 않았습니다)

retain 가 있었으면 정말 좋았을 것 같아요.
&mut T 를 술어에 전달하고 제거된 값을 반환했을 수 있습니다.
retain 가 더 직관적인 이름 기반이라고 생각하기 때문입니다.

그러나 이것과는 별개로 나는 drain_filter / drain_retain 모두 차선책이라고 생각합니다.
술어가 항목을 유지/비우기 위해 true/false를 반환해야 하는지 여부를 명확히 하지 않기 때문입니다.
(드레인은 true가 필터를 제거하는 동안 요소 제거에 대해 말하므로 제거함을 나타냅니다.
그리고 재훈련은 어떤 요소를 유지해야 하는지를 말하며, 마침내 녹슬게 됩니다.)

결국 어떤 이름이 사용되는지가 _그_ 중요한 것이 아니라 안정화되면 좋을 것입니다.

설문 조사를 하거나 언어 팀의 누군가가 결정하도록 하는 것이 생각을 발전시키는 가장 좋은 방법이 될 수 있습니까?

drain_where , drain_if 또는 drain_when 와 같은 것이 drain_filter 보다 훨씬 명확하다고 생각합니다.

@tmccombs 그 3가지 중 drain_where 가 가장 합리적이라고 생각합니다. ( if 는 either do the whole thing (in this case draining) or not $를 의미하고 when 는 일시적이기 때문입니다.)
drain_filter 와 비교하면 클로저 반환 값은 drain_where (요소를 제거하는 true )와 동일하지만 그 사실은 이름에 의해 더 명확/명료해 지므로 제거됩니다. 클로저 반환 값의 의미를 실수로 잘못 해석할 위험이 있습니다.

안정될 때가 되었다고 생각합니다. 이 스레드 요약:

• R: RangeArgument 매개변수를 추가해야 합니까?
• 부울 값을 반전시켜야 합니까? (현재 논리가 의미가 있다고 생각합니다. 콜백에서 true 를 반환하면 해당 항목이 반복기에 포함됩니다.)
• 네이밍. (나는 drain_where 를 좋아한다.)

@Gankro , 어떻게 생각해?

libs 팀은 이에 대해 논의했으며 현재로서는 drain 같은 메서드를 더 이상 안정화 하지 않는 것이 합의였습니다. (기존의 drain_filter 메서드는 Nightly에서 불안정한 상태로 남을 수 있습니다.) https://github.com/rust-lang/rfcs/pull/2369 는 드롭될 때 아무 것도 하지 않는 또 다른 배수 같은 반복자를 추가할 것을 제안합니다. (반복자를 끝까지 소비하는 것과 반대).

다양한 배수 조합 조합을 더 작은 API 표면으로 일반화하려는 실험을 보고 싶습니다.

• 하위 범위( RangeArgument aka RangeBounds ) 대 전체 컬렉션(후자는 .. , RangeFull 유형의 값을 전달하여 달성할 수 있음) ).
• 모든 것(해당 범위 내에서 가능) 비우기 대 부울 술어와 일치하는 요소만
• 드롭 대 자체 소진(나머지 요소는 컬렉션에 남겨둠).

가능성에는 메소드를 일반화하거나 빌더 패턴을 "오버로드"하는 것이 포함될 수 있습니다.

한 가지 제약 조건은 drain 메서드가 안정적이라는 것입니다. 일반화할 수는 있지만 이전 버전과 호환되는 방식으로만 가능합니다.

다양한 배수 조합 조합을 더 작은 API 표면으로 일반화하려는 실험을 보고 싶습니다.

팀은 이러한 유형의 실험이 발생하는 방법과 위치를 예측합니까?

방법: 개념 증명 구현(적어도 Vec::as_mut_ptr 및 Vec::set_len 통해 트리 외부에서 수행 가능)을 사용하여 구체적인 API 설계를 제안하고 제안합니다. 장소는 그다지 중요하지 않습니다. https://internals.rust-lang.org/c/libs 의 새 RFC 또는 스레드일 수 있으며 여기에서 링크합니다.

나는 이것으로 잠시 놀고 있었다. 다음 날 내부에 대한 스레드를 열겠습니다.

다음과 같이 작동하는 일반 API가 의미가 있다고 생각합니다.

    v.drain(a..b).where(pred)

따라서 빌더 스타일 API입니다. .where(pred) 가 추가되지 않으면 무조건 전체 범위가 소모됩니다.
여기에는 현재 .drain(a..b) 메서드와 .drain_filter(pred) 의 기능이 포함됩니다.

drain 이름이 이미 사용 중이어서 사용할 수 없는 경우 drain_iter 와 같은 유사한 이름이어야 합니다.

where 메서드의 이름은 *_filter 로 지정하면 안 됩니다. 특히 where 및 filter 가 다음과 같이 조합되어 사용되는 경우 결과 반복자를 필터링하는 것과 혼동을 피하기 위해서입니다.

    v.drain(..).where(pred1).filter(pred2)

여기서 pred1 를 사용하여 배수(및 반복자에서 전달)할 항목을 결정하고 pred2 를 사용하여 결과 반복자를 필터링합니다.
pred1 가 true 를 반환하지만 pred2 가 false 를 반환하는 모든 요소는 여전히 v 에서 소진되지만 이 결합된 반복자.

이러한 종류의 빌더 스타일 API 접근 방식에 대해 어떻게 생각하십니까?

잠시 동안 나는 where 가 이미 키워드이기 때문에 함수 이름으로 사용할 수 없다는 것을 잊었습니다 :/

그리고 drain 는 이미 안정화 되어 있어서 이름도 사용할 수 없습니다..

그런 다음 두 번째로 좋은 전체 옵션은 현재 drain 를 유지하고 .drain(..).filter() 와 혼동을 피하기 위해 drain_filter 의 이름을 drain_where 로 바꾸는 것입니다.

(위의 joonhoo가 말했듯이 : )

이 드레인_필터의 이름을 drain_where가 아닌 이유가 무엇입니까? 나에게 전자는 전체 Vec이 배수될 것이라는 것을 의미하지만 결과에 대해 필터도 실행한다는 것을 의미합니다. ?"). 반면에 전자는 어떤 조건이 유지되는 경우에만 요소를 배출한다는 것을 나타냅니다.

나는 내부에 스레드를 열었습니다.
TLDR은 non-self-exhaustion이 일반적인 경우 예상보다 더 큰 웜 캔이라고 생각하고 RangeBounds 매개 변수를 사용하여 나중에보다 빨리 drain_filter 를 안정화해야 한다고 생각합니다. 누군가 거기에 설명된 문제를 해결할 좋은 아이디어가 없는 한.

편집: 실험 코드를 업로드했습니다: 배수 실험
배수 및 청소 벤치와 일부 테스트도 있지만 깨끗한 코드를 기대하지는 않습니다.

이 스레드에서 완전히 빠졌습니다. 이 스레드에서 설명하는 몇 가지 옵션을 반영하기 위해 약간 수정하고 복사하여 붙여넣은 오래된 impl이 있습니다. 논쟁의 여지가 없다고 생각하는 impl에 대한 한 가지 좋은 점은 DoubleEndedIterator 를 구현한다는 것입니다. 여기에서 보십시오 .

@Emerentius 하지만 요소를 제거하기 위해 클로저가 true 를 반환해야 함을 나타내기 위해 최소한 drain_filter 의 이름을 drain_where 로 변경해야 합니다!

@Boscop 둘 다 true => yield의 동일한 '극성'을 의미합니다. 나는 개인적으로 그것이 drain_filter 또는 drain_where 인지 상관하지 않습니다.

@Popog 차이점과 장단점을 요약할 수 있습니까? 이상적으로는 내부 스레드에서 끝납니다. DoubleEndedIterator 기능은 0 또는 낮은 오버헤드와 호환 가능하게 추가될 수 있다고 생각합니다(그러나 테스트하지는 않았습니다).

drain_or_retain 는 어떻습니까? 이것은 문법적으로 의미 있는 행동이며 하나 또는 다른 하나를 수행한다는 신호입니다.

@askeksa 그러나 클로저에서 true 를 반환하는 것이 "드레인" 또는 "보유"를 의미하는지 명확하지 않습니다.
drain_where 와 같은 이름을 사용하면 true 를 반환하면 비워지는 것이 매우 분명하며 비워지지 않은 요소는 유지된다는 것이 모든 사람에게 분명해야 합니다.

배수를 제한/중지/취소/중단하는 방법이 있으면 좋을 것입니다. 예를 들어, 처음 N개의 짝수를 빼내고 싶다면 vec.drain_filter(|x| *x % 2 == 0).take(N).collect() (또는 그 변형)을 수행할 수 있으면 좋을 것입니다.

현재 구현되어 있으므로 DrainFilter 의 drop 메서드는 항상 완료될 때까지 배수를 실행합니다. 그것은 중단될 수 없습니다(적어도 나는 그렇게 할 수 있는 어떤 트릭도 알아내지 못했습니다).

해당 동작을 원하면 본 횟수를 추적하는 일부 상태를 닫고 false를 반환하기 시작해야 합니다. 어댑터가 합리적으로 작동하도록 하려면 드롭 시 완료까지 실행해야 합니다.

drain_filter 가 현재 구현되어 있는 방식이 안전하지 않지만
실제로 안전 위험 wrt. 긴장을 풀고 안전을 재개하십시오. 또한 쉽게 중단을 유발합니다.
그 중 std의 메소드가 실제로 해서는 안되는 동작입니다. 그리고 이 글을 쓰면서 나는 깨달았다.현재 구현이 안전하지 않다는 것

Vec 는 기본적으로 안전하지 않지만 drain_filer 의 동작은
술어 공황은 다음과 같은 이유로 매우 놀랍습니다.

1. 드롭 시 패닉 상태가 된 클로저를 계속 호출합니다.
   폐쇄가 다시 패닉을 일으키면 탑승을 일으키고 일부 사람들은
   오류 커널 패턴을 사용하는 다른 작업에 참여하는 모든 패닉과 마찬가지로
   승선으로 끝나는 것은 아주 나쁘다
2. 잠재적으로 하나의 값을 올바르게 계속 배출하지 않는 경우
   이미 드롭된 하나의 값을 포함하여 잠재적으로 무료 이후에 사용할 수 있습니다.

이 동작의 예는 다음과 같습니다.
play.rust-lang.org

2. 요점은 해결할 수 있어야 하지만 첫 번째 요점 자체는 다음과 같아야 한다고 생각합니다.
DrainFilter 의 행동을 재고하기 위해 실행 완료
이를 변경하는 이유는 다음과 같습니다.

• 반복자는 녹에 게으르며, 삭제할 때 반복자를 실행하는 것은 다소 예기치 않은 동작입니다.
  일반적으로 예상되는 것에서 파생
• drain_filter 에 전달된 술어는 일부 상황에서 패닉 상태일 수 있습니다(예: 잠금
  중독됨) 이 경우 드롭 리딩 중에 호출될 때 다시 당황할 가능성이 높습니다.
  오류 커널을 사용하는 사람에게는 매우 나쁩니다.
  패턴을 사용하거나 마침내 제어된 방식으로 종료하려는 경우, 어쨌든 panic=aboard를 사용하면 괜찮습니다.
• 술어에 부작용이 있고 DrainFilter 를 완료할 때까지 실행하지 않으면 다음을 얻을 수 있습니다.
  드롭될 때 완료될 때까지 실행될 때 놀라운 버그(하지만 완료했을 수도 있습니다.
  다른 사람은 그것을 포인트로 배수하는 것과 떨어 뜨리는 것 사이에서 생각합니다)
• 전달된 술어를 수정하지 않고는 이 동작을 옵트아웃할 수 없습니다.
  그것을 포장하지 않고는 할 수 없을 수도 있습니다. 반면에 항상 실행하도록 선택할 수 있습니다.
  iterator를 실행하여 완료하면 완료됩니다(예, 이 마지막 인수는 약간
  핸드웨이브)

실행 완료에 대한 인수는 다음과 같습니다.

• drain_filter 는 함수인 ratain 와 비슷해서 사람들이
  "그냥" DrainFilter 를 완료까지 실행하는 대신 삭제합니다.
  
  
  
  • 이 인수는 다른 RFC에서 여러 번 반박되었으며 이것이 #[unused_must_use] 입니다.
    
    어떤 상황에서는 이미 .for_each(drop) 를 사용하는 것이 좋습니다.
    
    DrainFilter 가 드롭에서 하는 일
  
  
• drain_filter 는 종종 부작용으로만 사용되므로 장황합니다.
  
  
  
  • 그런 식으로 사용하면 retain 와 거의 같습니다.
    
    
    
    
    
    • 그러나 &T 사용 유지 , drain_filter 사용 &mut T
    
    
    
  
  
• 다른 사람들??
• [EDIT, ADDED LATER, THX @tmccombs ]: find , all , any 와 같은 어댑터와 결합하면 드롭 시 완료되지 않는 것이 매우 혼란스러울 수 있습니다. 현재의 행동을 유지하기 위해.

저만 그럴 수도 있고 어떤 시점을 놓쳤을 수도 있지만 Drop 동작을 변경하고
#[unused_must_use] 를 추가하는 것이 더 나은 것 같습니까?

.for_each(drop) 가 너무 길면 대신 다음을 위한 반복자용 RFC를 추가하는 것을 고려할 수 있습니다.
complete() 와 같은 메소드를 iterator에 추가하는 부작용이 있습니다(또는 drain() 하지만 이것은
완전히 다른 토론입니다)

다른 사람들??

원래 추론을 찾을 수 없지만 완료까지 실행되지 않는 DrainFilter 와 함께 작동하는 어댑터에 약간의 문제도 있었던 것으로 기억합니다.

https://github.com/rust-lang/rust/issues/43244#issuecomment -394405057도 참조하십시오.

좋은 점, 예를 들어 find 는 첫 번째 히트가 될 때까지 배수가 배수되도록 합니다.
일치, 유사한 all , any 단락을 수행하므로 상당히 혼란스러울 수 있습니다.
워트. 물을 빼다.

흠, 생각을 바꿔야 할 것 같습니다. 이를 통해 일반적인 문제가 될 수 있습니다.
iterator에 부작용이 있고 일반적인 솔루션을 고려해야 할 수도 있습니다.
(이 추적 문제와 무관) .allways_complete() 어댑터와 같습니다.

개인적으로 배수구가 완료될 때까지 실행해야 하는 안전상의 이유를 찾지 못했지만 여기 에 위의 몇 가지 게시물을 쓴 것처럼 next() 에 대한 부작용은 take_while 과 같은 어댑터와 차선의 방식으로 상호 작용합니다. peekable 및 skip_while .

이것은 또한 non-self-exhausting 배수구 및 동반자 self- exhausting iter 어댑터 RFC 에 대한 내 RFC와 동일한 문제를 야기합니다.

drain_filter 가 쉽게 중단을 유발할 수 있는 것이 사실이지만 안전을 위반한 사례를 보여줄 수 있습니까?

네, 이미 했습니다: play.rust-lang.org

이것은 다음과 같습니다.

#![feature(drain_filter)]

use std::panic::catch_unwind;

struct PrintOnDrop {
    id: u8
}

impl Drop for PrintOnDrop {
    fn drop(&mut self) {
        println!("dropped: {}", self.id)
    }
}

fn main() {
    println!("-- start --");
    let _ = catch_unwind(move || {
        let mut a: Vec<_> = [0, 1, 4, 5, 6].iter()
            .map(|&id| PrintOnDrop { id })
            .collect::<Vec<_>>();

        let drain = a.drain_filter(|dc| {
            if dc.id == 4 { panic!("let's say a unwrap went wrong"); }
            dc.id < 4
        });

        drain.for_each(::std::mem::drop);
    });
    println!("-- end --");
    //output:
    // -- start --
    // dropped: 0    <-\
    // dropped: 1       \_ this is a double drop
    // dropped: 0  _  <-/
    // dropped: 5   \------ here 4 got leaked (kind fine)  
    // dropped: 6
    // -- end --

}

그러나 그것은 잘못된 구현 내부 생각입니다.
기본적으로 열린 질문은 술어 함수의 panic 를 처리하는 방법입니다.

1. 패닉에 빠진 요소를 건너뛰고 누출하고 del 카운터를 늘립니다.
   
   
   
   • 어떤 형태의 공황 감지가 필요합니다.
   
   
2. 술어를 호출하기 전에 idx를 진행하지 마십시오.
   
   
   
   • 그러나 이것은 on drop이 동일한 술어로 다시 호출한다는 것을 의미합니다.
   
   

또 다른 질문은 드롭 시 API 사용자 입력으로 볼 수 있는 기능을 실행하는 것이 좋은 아이디어인지 여부입니다.
일반적으로 이것은 find , any 등이 혼란스럽게 행동하지 않도록 하는 유일한 방법입니다.

고려 사항은 다음과 같을 수 있습니다.

1. next 를 입력할 때 플래그를 설정하고 next 에서 반환하기 전에 설정을 해제합니다.
2. 플래그가 여전히 설정되어 있으면 드롭 시 우리는 당황하여 누출된다는 것을 알고 있습니다.
   나머지 항목 또는 나머지 항목 모두 삭제
   
   
   
   1. 예를 들어 Arc를 누출하는 경우 예기치 않은 부작용이 있는 상당히 큰 누출이 될 수 있습니다.
   
   
   2. Arc와 Weak이 있으면 매우 놀랄 수 있습니다.
   
   

더 나은 솔루션이 있을 수 있습니다.
그것이 무엇이든 일단 구현되면 Rustdoc에 문서화되어야 합니다.

@dathinab

네, 이미 했어요

누출은 바람직하지 않지만 괜찮고 여기에서 피하기 어려울 수 있지만 이중 드롭은 확실히 아닙니다. 좋은 캐치! 이 안전 문제에 대해 별도의 문제를 보고하시겠습니까?

drain_filter 는 컬렉션에서 항목을 제거할 때마다 재할당을 수행합니까? 아니면 한 번만 재할당하고 C++에서 std::remove 및 std::erase (쌍으로)처럼 작동합니까? 나는 정확히 하나의 할당 때문에 그러한 행동을 선호합니다. 우리는 단순히 컬렉션의 끝에 요소를 넣은 다음 적절한 크기로 축소를 제거합니다.

또한 try_drain_filter 가 없는 이유는 무엇입니까? 중지해야 하는 경우 Option 유형과 None 값을 반환하는 것은 무엇입니까? 나는 매우 큰 컬렉션을 가지고 있으며 내가 필요한 것을 이미 얻었을 때 계속하는 것은 의미가 없습니다.

내가 마지막으로 코드를 가져왔을 때 다음과 같은 작업을 수행했습니다. "갭" 생성
요소를 이동하고 배수되지 않은 요소를 이동할 때
하나를 찾을 때 간격의 시작. 이것으로 각 요소는
이동(배열의 새 위치 또는 외부로)은 한 번만 이동됩니다.
또한 remove 와 같이 재할당하지 않습니다. 해방된 부분은
사용하지 않은 용량의 일부.

2018년 8월 10일 금요일 07:11 Victor Polevoy [email protected] 에서 다음과 같이 썼습니다.

drain_filter는 항목을 제거할 때마다 재할당을 수행합니까?
수집? 또는 재할당을 한 번만 수행하고 std::remove와 같이 작동합니다.
C++에서 std::erase(쌍으로)? 나는 그러한 행동을 선호하기 때문에
정확히 하나의 할당: 단순히 컬렉션의 끝에 요소를 넣습니다.
그런 다음 적절한 크기로 축소합니다.

또한 try_drain_filter가 없는 이유는 무엇입니까? Option 유형을 반환하고
멈춰야 한다면 가치가 없습니까? 나는 매우 큰 컬렉션을 가지고 있으며
이미 필요한 것을 얻었을 때 계속하는 것은 의미가 없습니다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/rust-lang/rust/issues/43244#issuecomment-411977001 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AHR0kdOZm4bj6iR9Hj831Qh72d36BxQSks5uPRYNgaJpZM4OY1me
.

@rustonaut 감사합니다. try_drain_filter 에 대해 어떻게 생각하십니까? :)

추신: 코드도 살펴보니 우리가 원하는 대로 작동하는 것 같습니다.

반복할 때 요소별로 진행하므로 일반적으로 예상할 수 있습니다.
드롭될 때 반복을 중지하지만 너무 많은 것으로 간주되었습니다.
혼란스러워서 실제로 떨어뜨렸을 때 끝까지 배수됩니다.
(이는 이중 공황과 물건의 가능성을 크게 증가시킵니다.
그런).

따라서 당신처럼 행동하는 시도 버전을 얻을 가능성은 거의 없습니다.
예상하다.

공정성을 위해 반복이 실제로 혼란스러울 때 조기 중지
thing.drain_where(|x| x.is_malformed()).any(|x| x.is_dangerus()) 와 같은 일부 상황은 모든 기형을 배수하지 않고 다음 중 하나가 발생할 때까지
또한 위험한 것으로 나타났습니다. (현재 Impl.은 모든 기형을 드레인합니다.
방울에 계속 배수함으로써).

2018년 8월 10일 금요일 10:52 Victor Polevoy [email protected] 에서 다음과 같이 썼습니다.

@rustonaut https://github.com/rustonaut 감사합니다. 당신의 의견 것입니다
try_drain_filter에 대해? :)

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/rust-lang/rust/issues/43244#issuecomment-412020490 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AHR0kcEMHCayqvhI6D4LK4ITG2x5di-9ks5uPUnpgaJpZM4OY1me
.

나는 이것이 더 다재다능하다고 생각합니다.

fn drain_filter_map<F>(&mut self, f: F) -> DrainFilterMap<T, F> where F: FnMut(T) -> Option<T>

안녕하세요, 저는 HashMap 에 대한 drain_filter 기능을 찾고 있었지만 존재하지 않으며 이 기능을 찾았을 때 문제를 열어달라는 요청을 받았습니다. 별도의 문제로 다루어야 합니까?

현재 안정화를 방해하는 것이 있습니까? 위에 보고된 대로 여전히 안전하지 않은 상태를 해제합니까?

이것은 아주 작은 기능처럼 보이며 1년 넘게 흐릿한 상태에 있었습니다.

나는 이것이 더 다재다능하다고 생각합니다.

fn drain_filter_map<F>(&mut self, f: F) -> DrainFilterMap<T, F> where F: FnMut(T) -> Option<T>

drain_filter 및 map 의 구성보다 낫다고 생각하지 않습니다.

위에 보고된 대로 여전히 안전하지 않은 상태를 해제합니까?

반복이 일찍 중지되면 일치하는 모든 요소를 ​​배수하지 않는 것과 DrainFilter 드롭에서 필터링 및 배수가 끝까지 수행되는 경우 해제하는 동안 잠재적인 패닉 사이에서 어려운 선택이 있는 것으로 보입니다.
이 기능은 어느 쪽이든 문제가 많기 때문에 안정화되어서는 안 된다고 생각합니다.

해제 시 다르게 동작하도록 하는 데 특별한 문제가 있습니까?

가능성:

• 정상적으로 완료될 때까지 실행할 수 있지만 해제 시 일치하는 요소를 남겨둡니다(나머지 모든 요소가 일치하지 않는 것으로 가정됨).
• 정상적으로 완료될 때까지 실행할 수 있지만 해제 시 마지막으로 기록된 위치 뒤에서 벡터를 자릅니다(나머지 모든 요소가 일치하는 것으로 가정됨).
• 정상적으로 완료될 때까지 실행할 수 있지만 해제 시 벡터를 길이 0으로 자릅니다.

내가 생각할 수 있는 가장 이해하기 쉬운 반론은 일반적으로 drain_filter 에 의해 제공되는 불변에 의존하는 drop 코드입니다(즉, 결국 vec의 요소는 정확히 다음과 같습니다. 조건이 실패함)은 drain_filter 를 사용하는 코드(대부분 정상적이고 안전한 코드)에서 임의로 멀 수 있습니다.

그러나 그러한 경우가 있다고 가정합니다. 이 코드는 사용자가 어떻게 작성하든 버그가 있습니다. 예를 들어 역방향으로 이동하고 요소를 교체하는 명령형 루프를 작성하는 경우 해당 조건이 패닉 상태가 될 수 있고 드롭 impl이 필터 조건이 false인 것에 크게 의존하는 경우 코드에는 여전히 버그가 있습니다. drop_filter 와 같은 기능을 갖고 있는 문서가 이 극단적인 경우에 주의를 환기시킬 수 있는 것은 비교하면 개선 된 것 같습니다.

또한 현재 구현 이 여전히 요소를 이중 드롭 한다는 것을 보여주는 스레드의 앞부분에 게시된 이 플레이그라운드 예제를 발견했습니다. (그래서 이대로는 절대 안정될 수 없다!)

건전성 버그에 대한 별도의 문제를 여는 것이 가치가 있습니까? 그런 다음 I-unsound로 표시될 수 있습니다.

내가 아는 한 당신은 표시를 할 수 없거나 더블 패닉만큼 건전하지 않습니다 _건전합니다_
중단될 때 매우 불편합니다. 또한 내가 기억하는 한
이중 패닉의 가능성은 버그가 아니라 암묵적인 행동이지만
고의로 선택한.

옵션은 기본적으로 다음과 같습니다.

1. 드롭 시 완료까지 실행하지 마십시오.
2. 완료될 때까지 실행하지만 이중 패닉으로 인해 잠재적으로 중단됨
3. 패닉 중에 드롭 시 모든 "확인되지 않은" 요소를 드롭하십시오.
4. 패닉 상태에서 떨어뜨리고 완료하지 마십시오.

문제는 다음과 같습니다.

1. => 많은 사용 사례에서 예기치 않은 동작.
2. => 술어가 패닉을 일으킬 수 있는 경우, 특히 사용하는 경우 예기치 않은 중단
   요소를 "그냥" 제거하려면, 즉 반환된 반복자를 사용하지 않습니다.
3. => 공황 상태에 빠지는 것과 바깥에 있을 때의 예상치 못한 차이. 단지
   drop 함수에서 drain_filter를 사용하는 사람을 고려하십시오.
4. => 3 참조.

또는 다른 말로 하면 1. 정상적인 사용 사례에서 혼란을 야기하고, 2.
술어가 당황할 수 있는 경우 중단하기 3.,4. 당신이 정말로 할 수 없도록하십시오
drop 메서드에서 사용하지만 이제 거기에서 사용하는 기능은 어떻게 됩니까?
내부적으로 사용하지 않습니다.

이 옵션의 결과로 3.,4. 금지되어 있습니다. 옵션 2의 문제는 다음과 같습니다.
1.에 있는 것보다 더 희귀하므로 2.가 선택되었습니다.

IMHO 실행되지 않는 drain+drain_filter API를 사용하는 것이 좋습니다.
드롭 시 완료 + 다음으로 실행되는 일반 반복자 결합기
삭제 시 완료 + 반복자를 완료하지만 모두 삭제하는 메서드
나머지 항목. 문제는 배수가 이미 안정적이고 반복자가
결합자는 내부 반복자와 드레인을 융합해야 하므로 오버헤드를 추가합니다.
가장 적절한 이름이 아닐 수 있습니다.

2019년 5월 20일 월요일 09:28 Ralf Jung 알림 @github.com 작성:

건전성 버그에 대한 별도의 문제를 여는 것이 가치가 있습니까? 그 수
그런 다음 I-unsound로 표시됩니다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/rust-lang/rust/issues/43244?email_source=notifications&email_token=AB2HJEL7FS6AA2A2KF5U2S3PWJHK7A5CNFSM4DTDLGPKYY3PNVWWK3TUL52HS4DFVEXG43VMXVB
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AB2HJEMHQFRTCH6RCQQ64DTPWJHK7ANCNFSM4DTDLGPA
.

그러나 더블 드롭 은 건전하지 않습니다.

건전성 문제를 위해 생성된 #60977

감사합니다. Double Panic :man_facepalming: 으로 double drop을 읽는 것이 어리석은 것 같습니다.

1. => 공황 상태에 빠지는 것과 바깥에 있을 때의 예상치 못한 차이. 단지
   drop 함수에서 drain_filter를 사용하는 사람을 고려하십시오.

3.,4. 당신이 정말로 할 수 없도록하십시오
drop 메서드에서 사용하지만 이제 거기에서 사용하는 기능은 어떻게 됩니까?
내부적으로 사용하지 않습니다.

이것은 나에게 여전히 큰 문제가 아닙니다.

누군가 패닉 상태가 될 수 있는 Drop impl에서 drain_filter 를 사용하는 경우 문제는 drain_filter 사용을 선택한 것이 아닙니다. 마찬가지로 메서드가 내부적으로 drain_filter 를 사용하는지 여부는 중요하지 않습니다.

죄송합니다. 너무 일찍 응답했습니다. 무슨 말인지 이제 알 것 같아요. 조금 더 고민해 보겠습니다.

좋아, 그래서 당신의 주장은 drain_filter 를 사용하는 drop impl 내부의 코드가 해제 중에 실행되면 불가사의하게 깨질 수 있다는 것입니다. (이것은 drain_filter 패닉에 대한 것이 아니라 drain_filter 실행을 유발하는 다른 코드 패닉에 관한 것입니다):

impl Drop for Type {
    fn drop(&mut self) {
        self.vec.drain_filter(|x| x == 3);

        // Do stuff that assumes the vector has no 3's
        ...
    }
}

이 드롭 impl은 해제하는 동안 갑자기 오작동합니다.

이것은 실제로 현재 스레드가 패닉 상태인지 여부를 DrainFilter가 순진하게 감지하도록 하는 것에 반대하는 강력한 주장입니다.

이후로 drain_filter 용어가 가장 유용합니다. 모든 항목을 제거하기 위한 drain 가 이미 있는 경우 제거할 항목을 선택하는 것은 filter 입니다. 함께 짝을 지으면 이름이 매우 일관되게 느껴집니다.

이중 패닉 건전성 문제에 대한 수정은 술어에 패닉이 발생할 경우 Vec 의 나머지 부분을 그대로 유지합니다. 항목은 간격을 채우기 위해 뒤로 이동하지만 그렇지 않으면 그대로 남습니다(풀기 중 Vec::drop 를 통해 삭제되거나 패닉이 포착된 경우 사용자가 처리함).

vec::DrainFilter 를 조기에 삭제하면 마치 완전히 소모된 것처럼 계속 작동합니다( vec::Drain 와 동일). vec::Drain::drop 동안 술어가 패닉하면 나머지 항목은 정상적으로 백시프트되지만 더 이상 항목이 삭제되지 않고 술어가 다시 호출되지 않습니다. 술어의 패닉이 정상적인 소비 중에 발생하는지 또는 vec::DrainFilter 가 삭제될 때 발생하는지 여부에 관계없이 본질적으로 동일하게 동작합니다.

건전성 구멍에 대한 수정이 정확하다고 가정할 때 이 기능의 안정화를 방해하는 또 다른 요소는 무엇입니까?

Vec::drain_filter 는 LinkedList::drain_filter 와 독립적으로 안정화될 수 있습니까?

drain_filter 용어의 문제는 drain_filter 의 경우 실제로 두 개의 출력이 있다는 것입니다. 반환 값과 원래 컬렉션이며 어느 쪽이 "필터링"되었는지 명확하지 않습니다. 항목이 계속됩니다. filtered_drain 도 조금 더 명확하다고 생각합니다.

"필터링된" 항목이 어느 쪽에서 진행되는지는 명확하지 않습니다.

Vec::drain 선례를 설정합니다. _제거_하려는 항목의 범위를 지정합니다. Vec::drain_filter 도 같은 방식으로 작동합니다. _제거_하려는 항목을 식별합니다.

"필터링된" 항목이 어느 쪽에서 진행되는지 명확하지 않습니다.

나는 이것이 Iterator::filter 에 대해 이미 사실이라고 생각합니다. 그래서 나는 그것을 사용할 때마다 문서를 보거나 테스트를 작성해야 하는 것을 포기했습니다. drain_filter 도 마찬가지입니다.

Ruby의 select 및 reject 용어를 선택했으면 좋겠지만 그 배는 이미 출항한 지 오래입니다.

이에 대한 진전이 있습니까? 이름이 아직 불확실한 유일한 것입니까?

이것이 안정화되는 것을 방해하는 것이 있습니까?

DrainFilter 의 Drop impl 은 소멸자 중 하나라도 술어 패닉에 빠지면 항목을 누출하는 것처럼 보입니다. 이것이 https://github.com/rust-lang/rust/issues/52267의 근본 원인입니다. 그런 API를 안정화하고 싶습니까?

신경 쓰지 마세요. 분명히 https://github.com/rust-lang/rust/pull/61224 에 의해 수정되었습니다.

이 추적 문제도 조금 짚고 넘어가겠습니다. 이 기능이 안정적으로 작동했으면 좋겠습니다. D 차단기가 있습니까?

cc @Dylan-DPC

drain drain_filter 가 RangeBounds 매개변수를 사용하도록 하는 데 찬성 또는 반대하는 결정이 내려진 적이 있습니까? 전체 벡터를 필터링하려는 경우 .. 를 전달하는 것이 충분히 쉬워보이므로 추가하는 것이 좋습니다.

나는 이것이 더 다재다능하다고 생각합니다.

fn drain_filter_map<F>(&mut self, f: F) -> DrainFilterMap<T, F> where F: FnMut(T) -> Option<T>

거의, 더 일반적인 버전은 Iterator::{filter_map, find_map, map_while} FnMut(T) -> Option<U> 사용합니다. 이런 식으로 filter_map 를 일반화할 가치가 있는지는 모르겠지만 고려해 볼 가치가 있습니다.

위에서 제안한 @jethrogb 방법을 다소 정확하게 찾고 있었기 때문에 여기에 도착했습니다.

fn drain_filter_map<F>(&mut self, f: F) -> DrainFilterMap<T, F>
    where F: FnMut(T) -> Option<T>

내가 염두에 두고 있던 것(내 머리 속에서 update 이라고 부름)과의 유일한 차이점은 배수 반복자를 반환하도록 생각하지 않았다는 것입니다. 항목 업데이트, 기존 항목 제거 및 제거된 항목을 호출자에게 전달하는 것을 지원하는 합리적으로 간단한 단일 인터페이스.

거의 대부분의 일반적인 버전은 Iterator::{filter_map, find_map, map_while} FnMut(T) -> Option<U> 를 사용합니다. 이런 식으로 filter_map 를 일반화할 가치가 있는지 모르겠지만 고려해 볼 가치가 있습니다.

이 함수는 생성하는 값이 Vec<T> 에 저장되기 때문에 Option<T> 를 반환해야 합니다.

@johnw42 내가 팔로우하고 있는지 잘 모르겠습니다. Some 값이 iterator에 의해 즉시 산출되지 않을까요?

사실, 그 함수의 입력 값은 여전히 T #$ 대신 &T 또는 &mut T 여야 합니다. 또는 함수는 FnMut(T) -> Result<U, T> 와 같을 수 있습니다. 하지만 항목 유형이 다른 유형이 될 수 없는 이유를 모르겠습니다.

@timvermeulen 제 생각에는 우리가 제안을 다르게 해석하고 있다고 생각합니다.

내가 해석한 방식으로 Some 값은 Vec 에 다시 저장되고 None 는 원래 값이 반복자에 의해 생성되었음을 의미합니다. 그러면 클로저가 값을 제자리에 업데이트하거나 Vec 밖으로 이동할 수 있습니다. 이 글을 쓰면서 drain_filter 측면에서 구현할 수 있기 때문에 내 버전에 실제로 아무것도 추가되지 않는다는 것을 깨달았습니다.

fn drain_filter_map<F>(
    &mut self,
    mut f: F,
) -> DrainFilter<T, impl FnMut(&mut T) -> bool>
where
    F: FnMut(&T) -> Option<T>,
{
    self.drain_filter(move |value| match f(value) {
        Some(new_value) => {
            *value = new_value;
            false
        }
        None => true,
    })
}

반대로, 나는 drain_filter 의 결과를 매핑하는 것과 동일하기 때문에 귀하의 해석이별로 유용하지 않다고 생각했지만 작성하려고 시도했지만 같은 이유로 filter_map 가' t는 filter 다음에 map 를 호출하는 것과 같습니다.

@johnw42 아, 예, None 가 값이 Vec 에 있어야 함을 의미하기를 원했다고 생각했습니다.

따라서 FnMut(T) -> Result<U, T> 가 가장 일반적이지만 인체공학적이지 않을 수 있습니다. FnMut(&mut T) -> Option<U> 는 실제로 옵션이 아닙니다. 왜냐하면 그렇게 하면 일반적인 경우에 T 의 소유권을 가질 수 없기 때문입니다. FnMut(T) -> Result<U, T> 및 FnMut(&mut T) -> bool 가 유일한 옵션이라고 생각합니다.

@timvermeulen 저는 "가장 일반적인" 솔루션에 대해 이전에 말하기 시작했고 제 "가장 일반적인" 솔루션은 귀하의 솔루션과 달랐지만 동일한 결론에 도달했습니다. 실제로 사용하고 싶지 않습니다.

고급 사용자가 그 위에 더 멋진 추상화를 구축할 수 있는 매우 일반적인 방법을 만드는 데 여전히 약간의 가치가 있을 수 있습니다. 내가 말할 수 있는 한, drain 및 drain_filter 의 요점은 특히 인체 공학적인 API가 아니라-그렇지 않지만-에서 발생하는 사용 사례를 지원한다는 것입니다. 이는 많은 중복 이동 없이(또는 안전하지 않은 작업을 사용하여) 다른 방법으로 작성할 수 없습니다.

drain 를 사용하면 다음과 같은 멋진 속성을 얻을 수 있습니다.

• 요소의 연속 선택을 제거할 수 있습니다.
• 제거된 항목을 삭제하는 것은 반환된 반복자를 삭제하는 것만큼 간단합니다.
• 제거된 항목은 드롭할 필요가 없습니다. 호출자는 각 항목을 개별적으로 검사하고 수행할 작업을 선택할 수 있습니다.
• Vec 의 내용은 Copy 또는 Clone 를 지원할 필요가 없습니다.
• Vec 자체에 대한 메모리를 할당하거나 해제할 필요가 없습니다.
• Vec 에 남아 있는 값은 최대 한 번만 이동됩니다.

drain_filter 를 사용하면 연속 범위가 아니라 Vec 에서 임의의 항목 집합을 제거할 수 있습니다. 덜 분명한 이점은 연속적인 항목 범위가 제거되더라도 drain 에 전달할 범위를 찾는 데 $에 대한 별도의 전달을 포함하는 경우 Vec drain_filter 이 여전히 성능 향상을 제공할 수 있다는 것입니다. Vec 내용을 검사합니다. 클로저에 대한 인수가 &mut T 이기 때문에 Vec 에 남아 있는 항목을 업데이트하는 것도 가능합니다. 만세!

다음은 drain_filter 와 같은 내부 작업으로 수행할 수 있는 몇 가지 다른 작업입니다.

1. 반복자를 통해 반환하기 전에 제거된 항목을 변환합니다.
2. 작업을 일찍 중단하고 오류를 보고합니다.
3. 항목을 제거하거나 제자리에 두는 대신(변경할 수 있는 동안) 항목 을 제거하고 새 값(원래 값의 복제본 또는 완전히 다른 값일 수 있음)으로 대체하는 기능을 추가하십시오.
4. 제거된 항목을 여러 개의 새 항목으로 교체합니다.
5. 현재 항목으로 작업을 수행한 후 다음 항목 중 몇 개를 건너뛰고 제자리에 두십시오.
6. 현재 항목으로 작업을 수행한 후 다음 항목을 먼저 검사하지 않고 제거하십시오.

그리고 각각에 대한 분석은 다음과 같습니다.

1. 호출자는 반복자에 의해 반환된 항목을 이미 변환할 수 있기 때문에 유용한 것은 추가되지 않습니다. 또한 Vec 에서 제거된 후에만 호출자에게 값을 전달하여 값을 복제하는 것을 방지하는 반복자의 목적을 무효화합니다.
2. 조기에 중단할 수 있으면 일부 경우에 잠재적으로 점근적 복잡성을 개선할 수 있습니다. API의 일부로 오류를 보고하면 클로저가 캡처된 변수를 변경하도록 하여 동일한 작업을 수행할 수 있기 때문에 새로운 것이 추가되지 않으며, 반복자가 완료될 때까지 값이 생성되지 않기 때문에 수행 방법도 명확하지 않습니다. 소비되었다.
3. 이것은 실제 일반성을 추가한다고 생각합니다.
4. 이것은 원래 "주방 싱크" 옵션으로 제안하려고 했던 것이지만 하나의 항목을 여러 항목으로 대체할 수 있으면 Vec 에 있는 항목을 유지하는 것이 불가능하기 때문에 도움이 되지 않기로 결정했습니다. Vec 를 구축하는 것보다 반드시 더 효율적인 것은 아니며 더 나쁠 수 있습니다.
5. 이는 Vec 가 항목을 검사하기 위해 멈추지 않고 항목의 많은 부분을 건너뛸 수 있는 방식으로 구성되어 있는 경우에 유용할 수 있습니다. 아래 샘플 코드에는 포함하지 않았지만 계속하기 전에 다음 항목 중 몇 개를 건너뛸지 지정하는 추가 usize 를 반환하도록 클로저를 변경하여 지원할 수 있습니다.
6. 이것은 항목 5를 보완하는 것처럼 보이지만 반복자를 통해 제거된 항목을 반환해야 하는 경우에는 그다지 유용하지 않습니다. 제거하는 항목에 소멸자가 없고 단순히 사라지게 하려는 경우에는 여전히 유용한 최적화가 될 수 있습니다. 이 경우 위의 usize 는 Keep(usize) 또는 Drop(usize) (여기서 Keep(0) 및 Drop(0) 는 의미상 동등한).

클로저가 4가지 경우가 있는 열거형을 반환하도록 하여 필수 사용 사례를 지원할 수 있다고 생각합니다.

fn super_drain(&mut self, f: F) -> SuperDrainIter<T>
    where F: FnMut(&mut T) -> DrainAction<T>;

enum DrainAction<T>  {
    /// Leave the item in the Vec and don't return anything through
    /// the iterator.
    Keep,

    /// Remove the item from the Vec and return it through the
    /// iterator.
    Remove,

    /// Remove the item from the Vec, return it through the iterator,
    /// and swap a new value into the location of the removed item.
    Replace(T),

    /// Leave the item in place, don't return any more items through
    /// the iterator, and don't call the closure again.
    Stop,
}

마지막으로 제시하고 싶은 옵션은 반복자를 완전히 없애고, 항목을 값으로 클로저에 전달하고, 호출자가 항목을 변경하지 않고 그대로 두도록 하는 것입니다.

fn super_drain_by_value(&mut self, f: F)
    where F: FnMut(T) -> DrainAction<T>;

enum DrainAction<T>  {
    /// Don't replace the item removed from the Vec.
    Remove,

    /// Replace the item removed from the Vec which a new item.
    Replace(T),

    Stop,
}

이 접근 방식이 가장 마음에 듭니다. 간단하고 동일한 사용 사례를 모두 지원하기 때문입니다. 잠재적인 단점은 대부분의 항목이 제자리에 남아 있더라도 여전히 클로저의 스택 프레임으로 이동한 다음 클로저가 반환될 때 다시 이동해야 한다는 것입니다. 클로저가 인수를 반환할 때 이러한 이동이 안정적으로 최적화될 수 있기를 희망하지만 그것이 우리가 기대해야 하는 것인지 확실하지 않습니다. 다른 사람들이 그것을 포함할 만큼 충분히 마음에 든다면 update 가 좋은 이름이 될 것이라고 생각합니다. 왜냐하면 제가 틀리지 않으면 단일 패스 인플레이스 업데이트를 구현하는 데 사용할 수 있기 때문입니다. Vec 의 내용입니다.

(BTW, 나는 이 문제의 제목을 보기 전까지 완전히 잊어버렸기 때문에 위의 연결 목록을 완전히 무시했습니다. 연결 목록에 대해 이야기하면 포인트 4-6의 분석을 변경하므로 다른 생각입니다. API는 연결 목록에 적합합니다.)

@johnw42 3. 변경 가능한 참조가 있는 경우 mem::replace 또는 mem::take 를 사용하여 이미 할 수 있습니다.

@johnw42 @jplatte

(3) 반환된 Iterator 의 항목 유형이 컬렉션의 항목 유형과 다른 것을 허용하는 경우에만 실제로 의미가 있습니다.
(3)은 Iterator 에서 요소를 반환하고 Vec 에 새 요소를 다시 넣으므로 특별한 경우입니다.

Bikeshedding: Replace(T) 의 기능을 약간 반대로 하고 PushOut(T) PushOut 의 내부 값을 반복자에 "제출"하는 목적으로 Vec 의 원본(매개변수) 항목.

Stop 는 아마도 Error 유형을 반환하는 기능을 가지고 있어야 합니다(또는 try_fold 처럼 약간 작동합니까?).

어젯밤에 super_drain_by_value 기능을 구현했고 몇 가지를 배웠습니다.

헤드라인 항목은 아마도 Vec wrt 이상이어야 합니다. 여기서 우리가 이야기하는 모든 것은 (근본적으로 새로운 기능을 추가하는 것과는 대조적으로) "있으면 좋은" 범주에 속해야 합니다. 왜냐하면 Vec 는 이미 기본적으로 기존 API를 통해 모든 필드에 대한 직접적인 읽기 및 쓰기 액세스를 제공합니다. 안정 버전에는 비어 있는 Vec 의 포인터 필드를 관찰할 수 없다는 작은 경고가 있지만 불안정한 into_raw_parts 메서드는 해당 제한을 제거합니다. 우리가 실제로 말하는 것은 안전한 코드로 효율적으로 수행할 수 있는 작업 집합을 확장하는 것입니다.

코드 생성의 관점에서, 쉬운 경우(예: Vec<i32> )에서 Vec 안팎으로의 중복 이동은 문제가 되지 않으며 호출은 다음과 같은 단순한 문제에 해당합니다. no-op 또는 Vec 자르기는 개선하기에는 너무 간단한 코드로 변환됩니다(각각 0개 및 3개 명령어). 나쁜 소식은 더 어려운 경우에 내 제안과 drain_filter 메서드 모두 불필요한 복사를 많이 하여 메서드의 목적을 크게 상쇄한다는 것입니다. Vec<[u8; 1024]> 에 대해 생성된 어셈블리 코드를 보고 테스트했으며 두 경우 모두 각 반복에는 최적화되지 않은 memcpy 에 대한 두 개의 호출이 있습니다. no-op 호출조차도 전체 버퍼를 두 번 복사하는 것으로 끝납니다!

인체 공학의 관점에서 보면, 언뜻 보기에 꽤 괜찮아 보이는 내 API가 실제로는 그다지 좋지 않습니다. 클로저에서 열거형 값을 반환하는 것은 가장 단순한 경우를 제외하고는 모두 매우 장황하며, 클로저가 열거형 값 쌍을 반환하는 경우 내가 제안한 변형은 훨씬 더 추악합니다.

나는 또한 super_drain_by_value 에서 Option<R> $ 로 반환된 R 값을 전달하기 위해 DrainAction::Stop 를 확장하려고 시도했습니다. 반환된 값이 필요하지 않은 경우 컴파일러는 R 를 유추할 수 없으며 사용하지 않는 값의 유형에 명시적으로 주석을 달아야 합니다. 이러한 이유로 super_drain_by_value 호출자에게 클로저에서 값을 반환하는 것을 지원하는 것은 좋지 않다고 생각합니다. loop {} 구문이 값을 반환할 수 있지만 다른 종류의 루프가 () 로 평가되는 이유와 대략 유사합니다.

일반성과 관련하여 저는 조기 종료에 대해 실제로 두 가지 경우가 있음을 깨달았습니다. 하나는 Vec 의 나머지 부분이 삭제되고 다른 하나는 제자리에 남아 있습니다. 조기 종료가 값을 전달하지 않으면(내 생각대로) 의미상 Keep(n) 또는 Drop(n) 반환하는 것과 동일합니다. 여기서 n 는 아직 검토되지 않은 항목. 그러나 Keep / Drop 를 사용하는 것과 비교하여 더 간단한 코드 경로를 통해 사용하는 것이 더 쉽기 때문에 조기 종료는 별도의 경우로 처리되어야 한다고 생각합니다.

API를 좀 더 친숙하게 만들려면 클로저가 () 를 반환하고 이를 헬퍼 객체(여기서 "업데이터"라고 칭함)에 전달하는 것이 더 나은 옵션이라고 생각합니다. Vec 의 각 요소를 검사하고 어떤 일이 발생하는지 제어하는 ​​데 사용됩니다. 이러한 메서드는 keep_next(n) 또는 drop_remainder() 와 같은 추가 메서드와 함께 borrow , borrow_mut 및 take 와 같은 친숙한 이름을 가질 수 있습니다. 이러한 종류의 API를 사용하면 간단한 경우에 클로저가 훨씬 간단해지고 복잡한 경우에는 더 복잡하지 않습니다. 대부분의 업데이터 메서드가 값으로 self 를 사용하도록 하면 호출자가 take 를 두 번 이상 호출하거나 후속 반복에서 수행할 작업에 대해 충돌하는 지침을 제공하는 것과 같은 일을 하는 것을 방지하기 쉽습니다.

하지만 우리는 여전히 더 잘할 수 있습니다! 나는 오늘 아침에 종종 그렇듯이 이 문제가 함수형 언어에서 확실히 해결된 문제와 유사하며 유사한 솔루션으로 해결할 수 있다는 것을 깨달았습니다. 나는 OCaml의 샘플 코드를 사용하여 이 짧은 문서 에서 처음 설명하고 Haskell 코드와 다른 관련 문서에 대한 링크를 사용하여 여기 에 설명된 "zipper" API에 대해 이야기하고 있습니다. 지퍼는 데이터 구조를 탐색하고 특정 데이터 구조가 지원하는 작업을 사용하여 "제자리에서" 업데이트하는 매우 일반적인 방법을 제공합니다. 그것을 생각하는 또 다른 방법은 지퍼가 특정 유형의 데이터 구조에 대한 작업을 수행하기 위한 추가 방법이 있는 일종의 터보차저 반복기라는 것입니다.

Haskell에서는 지퍼를 모나드로 만들어 "제자리에" 의미를 부여합니다. Rust에서는 Vec 에 대한 mut 참조를 지퍼에 유지함으로써 수명을 사용하여 동일한 작업을 수행할 수 있습니다. Vec 에 대한 지퍼는 위에서 설명한 업데이터와 매우 유사합니다. 단, 클로저에 반복적으로 전달하는 대신 Vec 자체에 지퍼를 생성하는 방법을 제공하고, 지퍼는 Vec 가 존재하는 한 독점적으로 액세스할 수 있습니다. 그런 다음 호출자는 배열을 순회하는 루프를 작성하고 각 단계에서 메서드를 호출하여 Vec 에서 현재 항목을 제거하거나 그대로 두는 책임이 있습니다. 지퍼를 사용하는 메서드를 호출하여 조기 종료를 구현할 수 있습니다. 루프는 호출자의 제어 하에 있기 때문에 루프의 각 반복에서 둘 이상의 항목을 처리하거나 루프를 전혀 사용하지 않고 고정된 수의 항목을 처리하는 것과 같은 작업을 수행하는 것이 가능해집니다.

다음은 지퍼가 할 수 있는 몇 가지를 보여주는 매우 인위적인 예입니다.

/// Keep the first 100 items of `v`.  In the next 100 items of `v`,
/// double the even values, unconditionally keep anything following an
/// even value, discard negative values, and move odd values into a
/// new Vec.  Leave the rest of `v` unchanged.  Return the odd values
/// that were removed, along with a boolean flag indicating whether
/// the loop terminated early.
fn silly(v: &mut Vec<i32>) -> (bool, Vec<i32>) {
    let mut odds = Vec::new();
    // Create a zipper, which get exclusive access to `v`.
    let mut z = v.zipper();
    // Skip over the first 100 items, leaving them unchanged.
    z.keep_next(100);
    let stopped_early = loop {
        if let Some(item /* &mut i32 */) = z.current_mut() {
            if *item < 0 {
                // Discard the value and advance the zipper.
                z.take();
            } else if *item % 2 == 0 {
                // Update the item in place.
                *item *= 2;

                // Leave the updated item in `v`.  This has the
                // side-effect of advancing `z` to the next item.
                z.keep();

                // If there's another value, keep it regardless of
                // what it is.
                if z.current().is_some() {
                    z.keep();
                }
            } else {
                // Move an odd value out of `v`.
                odds.push(z.take());
            }
            if z.position() >= 200 {
                // This consumes `z`, so we must break out of the
                // loop!
                z.keep_rest();
                break true;
            }
        } else {
            // We've reached the end of `v`.
            break false;
        }
    }
    (stopped_early, odds)

    // If the zipper wasn't already consumed by calling
    // `z.keep_rest()`, the zipper is dropped here, which will shift
    // the contents of `v` to fill in any gaps created by removing
    // values.
}

비교를 위해 drain_filter 를 사용하는 거의 동일한 기능이 있습니다. 다만 일찍 멈추는 척하는 것뿐입니다. 거의 같은 양의 코드이지만 IMHO 클로저에서 반환된 값의 의미가 명확하지 않고 변경 가능한 부울 플래그를 사용하여 한 반복에서 다음 반복으로 정보를 전달하기 때문에 읽기가 훨씬 더 어렵습니다. 버전은 제어 흐름과 동일한 작업을 수행합니다. 제거된 항목은 항상 반복자에 의해 생성되기 때문에 출력에서 ​​음수 값을 제거하려면 별도의 필터 단계가 필요합니다. 즉, 한 곳이 아닌 두 곳에서 음수 값을 확인해야 합니다. v 의 위치를 ​​추적해야 하는 것도 추악합니다. drain_filter 구현에는 해당 정보가 있지만 호출자는 이에 액세스할 수 없습니다.

fn drain_filter_silly(v: &mut Vec<i32>) -> (bool, Vec<i32>) {
    let mut position: usize = 0;
    let mut keep_next = false;
    let mut stopped_early = false;
    let removed = v.drain_filter(|item| {
        position += 1;
        if position <= 100 {
            false
        } else if position > 200 {
            stopped_early = true;
            false
        } else if keep_next {
            keep_next = false;
            false
        } else if *item >= 0 && *item % 2 == 0 {
            *item *= 2;
            false
        } else {
            true
        }
    }).filter(|item| item >= 0).collect();
    (stopped_early, removed)
}

@johnw42 이전 게시물에서 scanmut crate , 특히 Remover struct 가 떠올랐고 언급한 "지퍼" 개념이 매우 유사해 보입니다! 그것은 완전한 제어를 원할 때 폐쇄를 취하는 방법보다 훨씬 더 인체 공학적으로 보입니다.

어느 쪽이든, 이것은 우리가 나중에 언제든지 내부를 교체할 수 있기 때문에 drain_filter 를 안정화해야 하는지 여부와 별로 관련이 없을 것입니다. drain_filter 자체는 편리하기 때문에 항상 매우 유용할 것입니다. 안정화 전에 여전히 보고 싶은 유일한 변경 사항은 RangeBounds 매개변수입니다.

@timvermeulen RangeBounds 매개변수를 추가하는 것이 합리적이라고 생각하지만 현재 클로저 서명( F: FnMut(&mut T) -> bool )을 유지합니다.
항상 filter_map 또는 원하는 대로 배수된 요소를 후처리할 수 있습니다.
(저에게는 retain 가 허용하지 않기 때문에 클로저가 요소 변경을 허용하는 것이 매우 중요합니다(이 실수가 발견되기 전에 안정화되었습니다).

네, 편리함과 유용함 사이의 완벽한 균형인 것 같습니다.

@timvermeulen 네, 저는 본론에서 다소 벗어나 있었습니다.

원래 주제와 관련하여 내가 발견한 한 가지는 클로저의 반환 값이 무엇을 의미하는지 기억하기가 다소 어렵다는 것입니다. 항목을 유지할지 아니면 제거할지를 말하는 것입니다. 문서가 v.drain_filter(p) 가 부작용이 있는 v.iter().filter(p) 와 동일하다는 점을 지적하는 것이 도움이 될 것이라고 생각합니다.

filter 를 사용하면 부울 값을 사용하는 것이 명확성을 위해 여전히 이상적이지 않지만 매우 잘 알려진 기능이며 IMHO는 술어가 "이것을 유지해야 하나요?"라는 질문에 대답하는 것이 적어도 다소 직관적입니다. "이것을 버려야 하나?"보다 drain_filter 를 사용하여 iterator의 관점에서 생각하면 동일한 논리가 적용되지만 입력 Vec 의 관점에서 생각하면 "should I NOT 이거 갖고있어?"

정확한 표현에 관해서는 filter 매개변수의 이름을 predicate 로 바꾸고 ( Iterator::filter 와 일치하도록) 설명의 어딘가에 이 문장을 추가하는 것이 좋습니다.

predicate 의 반환 값이 사용되는 방식을 기억하려면 drain_filter 가 Iterator::filter 와 동일하고 선택한 항목을 제거하는 추가 부작용이 있음을 기억하는 것이 도움이 될 수 있습니다. self 의 항목.

@johnw42 네, 좋은 지적입니다. drain_where 와 같은 이름이 훨씬 더 명확할 것 같습니다.

당신이 자전거 셰딩에 이름을 붙이려고 한다면; 모든 댓글을 읽었는지 확인 하십시오 . 숨겨진 것들까지도. 많은 변형이 이미 제안되었습니다(예: https://github.com/rust-lang/rust/issues/43244#issuecomment -331559537).

하지만... 이름 은 draintain() 여야 합니다! 다른 이름은 아름답지 않습니다!

저는 이 문제에 상당히 관심이 있으며 전체 스레드를 읽었으므로 이 문제가 안정화되는 데 도움이 되기를 바라며 모든 사람이 말한 내용을 요약하려고 합니다. 나는 도중에 내 자신의 의견을 추가했지만 가능한 한 중립을 유지하려고 노력했습니다.

네이밍

다음은 내가 제안한 이름에 대한 의견이 없는 요약입니다.

• drain_filter : 현재 구현에 사용된 이름입니다. filter_map 와 같은 다른 이름과 일치합니다. drain().filter() 와 유사하지만 부작용이 더 많다는 장점이 있습니다.
• drain_where : true 의 결과가 _out_을 배수하거나 _in_을 필터링하는지 여부를 나타내는 이점이 있습니다. 이는 다른 이름으로 기억하기 어려울 수 있습니다. std 에 _where 접미사에 대한 선례는 없지만 유사한 접미사에 대한 선례는 많습니다.
• where drain().where() 의 변형입니다.
• drain_retain : retain 와 일치하지만 retain 및 drain 는 클로저에서 반환된 부울 값에 대해 반대 해석을 하므로 혼동될 수 있습니다.
• filtered_drain
• drain_if
• drain_when
• remove_if

매개변수

drain 와의 일관성을 위해 range 인수를 추가하는 것이 좋습니다.

FnMut(&mut T) -> bool 및 FnMut(T) -> Result<T, U> 의 두 가지 폐쇄 형식이 제안되었습니다. 후자는 더 유연하지만 더 서툴다.

retain 와 일치하도록 부울 조건( true 은 " Vec 에 유지"를 의미)을 반전시키는 것이 논의되었지만 drain 와 일치하지 않을 것입니다. true 는 " Vec 에서 배수"를 의미).

긴장 풀기

필터 클로저 패닉이 발생하면 DrainFilter 반복자가 삭제됩니다. 그러면 반복자는 Vec 배수를 완료해야 하지만 그렇게 하려면 필터 클로저를 다시 호출해야 하므로 이중 패닉의 위험이 있습니다. 몇 가지 솔루션이 있지만 모두 절충안입니다.

• 떨어뜨리는 것을 끝내지 마십시오. 이것은 find 또는 all 와 같은 어댑터와 함께 사용할 때 상당히 직관적이지 않습니다. 게다가 반복자가 게으르므로 v.drain_filter(...); 관용구를 쓸모없게 만듭니다.

• 항상 드롭 시 배수를 완료하십시오. 이것은 두 배의 패닉(중단을 초래함)의 위험이 있지만 동작을 일관되게 만듭니다.

• 현재 풀고 있지 않은 경우에만 드롭 시 배수를 완료합니다. 이는 이중 패닉을 완전히 수정하지만 drain_filter DrainFilter 동작을 예측할 수 없게 만듭니다.

• 필터 클로저 가 패닉하지 않은 경우에만 배수를 완료하십시오. 이것은 drain_filter 가 만든 현재 절충안입니다. 이 접근 방식의 좋은 특성은 필터 폐쇄 "단락"에서 패닉이 발생한다는 것인데, 이는 틀림없이 매우 직관적입니다.

현재 구현은 건전하고 DrainFilter 구조체가 삭제되는 한 절대 누출되지 않습니다(중단을 유발할 수 있지만). 그러나 이전 구현은 안전하거나 누출이 없었습니다.

드랍온드롭

DrainIter 는 소스 벡터가 삭제될 때 배출을 완료하거나 next 가 호출될 때만 배출될 수 있습니다(지연 반복).

Drain-on-Drop에 찬성하는 주장:

• drain 의 동작과 일치합니다.

• all , any , find 등과 같은 다른 어댑터와 잘 상호 작용합니다.

• vec.drain_filter(...); 관용구를 활성화합니다.

• 게으른 기능은 drain_lazy 스타일 메서드 또는 DrainIter (심지어 Drain 에서도 이전 버전과 호환되므로 lazy() 어댑터)를 통해 명시적으로 활성화할 수 있습니다. 메소드 추가).

지연 반복에 찬성하는 주장:

• 거의 모든 다른 반복자와 일치합니다.

• "drain-on-drop" 기능은 DrainIter 의 어댑터를 통해 또는 일반 Iterator::exhausting 어댑터를 통해 명시적으로 활성화될 수 있습니다(RFC #2370 참조).

제가 놓친 부분이 있을 수도 있지만, 적어도 스레드를 훑어볼 때 초보자에게 도움이 되었으면 합니다.

@negamartin

drain-on-drop 옵션을 사용하려면 반복자가 소유한 값 대신 항목에 대한 참조를 반환해야 하지 않습니까? 특정 조건(내 원래 사용 사례)과 일치하는 항목을 제거하고 소유권을 가져오는 메커니즘으로 drain_filter 를 사용하는 것을 불가능하게 만들 것이라고 생각합니다.

저는 그렇게 생각하지 않습니다. 현재 구현의 동작은 소유한 값을 산출하면서 정확하게 소진되기 때문입니다. 어느 쪽이든, 나는 드레인-온-드롭이 차용 요소를 필요로 하는지 알지 못하므로, 드레인-온-드롭의 의미에 대해 두 가지 다른 아이디어가 있다고 생각합니다.

분명히 하자면, 내가 drop-on-drop이라고 할 때 반복자가 완전히 사용되지 않았을 때의 동작만을 의미합니다. 반복자가 완전히 사용되지 않더라도 클로저와 일치하는 모든 항목이 배수되어야 합니까? 아니면 소모된 요소까지만 사용하고 나머지는 그대로 두나요?

특히 다음과 같은 차이점이 있습니다.

let mut v = vec![1, 5, 3, 6, 4, 7];
v.drain_where(|e| *e > 4).find(|e| *e == 6);

// Drain-on-drop
assert_eq!(v, &[1, 3, 4]);

// Lazy
assert_eq!(v, &[1, 3, 4, 7]);

아이디어를 던지고 있지만 또 다른 가능한 API는 다음과 같을 수 있습니다.

 fn drain_filter_into<F, D>(&mut self, filter: F, drain: D)
        where F: FnMut(&mut T) -> bool, 
                   D: Extend<T>
    { ... }

다른 옵션보다 덜 유연하지만 DrainFilter 가 떨어졌을 때 무엇을 해야 하는지에 대한 문제를 피합니다.

나에게 이 모든 것이 retain_mut() ( 클로저에 전달된 변경 가능한 참조가 있는 retain() )처럼 점점 줄어들고 있는 것처럼 느껴집니다. . 여과된 배수 장치의 설계 작업 외에 지금 retain_mut() 을 제공할 수 있습니까? 아니면 내가 뭔가를 놓치고 있습니까?

@BartMassey

그것이 무엇보다 먼저 제공하고자 했던 것입니다.

나는 그것이 사실이라고 생각하지 않는다. 특히 drain_filter 를 사용하여 필터 기준에 따라 항목의 소유권을 가져옵니다. Drain 및 DrainFilter 는 유지하지 않는 항목을 제공합니다.

@negamartin

분명히 하자면, 내가 배수 중 드롭이라고 말하는 것은 반복자가 완전히 소비되지 않았을 때의 동작만을 의미합니다.

그래. 그건 내 실수야. 당신의 정의를 잘못 이해했습니다. 나는 그것을 "떨어질 때까지 vec에서 아무 것도 제거되지 않는다"로 해석했는데, 이것은 정말 의미가 없습니다.

지연 반복에 찬성하는 주장

drain 와 일치해야 한다고 생각합니다. Iterator::exhausting RFC는 승인되지 않았으며 drain 및 drain_filter 에 겉보기에 반대되는 배수 동작이 있는 경우 매우 이상합니다.

@negamartin

drain_filter: 현재 구현에 사용된 이름입니다. filter_map과 같은 다른 이름과 일치합니다. drain().filter() 와 유사하지만 부작용이 더 많다는 장점이 있습니다.

유사하지 않습니다(이것이 우리가 retain_mut / drain_filter 가 필요한 이유입니다):
drain().filter() 는 필터 클로저가 false 를 반환하는 요소도 배수합니다!

방금 #RFC 2870 lib 팀의 코멘트에서 작은 줄을 발견했습니다.

가능성에는 메소드를 일반화하거나 빌더 패턴을 "오버로드"하는 것이 포함될 수 있습니다.

이전의 구체적인 유형을 여전히 수락하는 경우 메서드를 제네릭으로 만드는 것이 이전 버전과 호환됩니까? 그렇다면 그것이 최선의 길이라고 생각합니다.

(빌더 패턴은 반복자의 메서드가 일반적으로 동작 변경자가 아니라 어댑터이기 때문에 반복자의 경우 약간 직관적이지 않습니다. 게다가 chunks 및 chunks_exact 는 두 개의 별도 메서드입니다. , chunks().exact() 콤보가 아닙니다.)

아니요, 내가 아는 한 현재 디자인이 아닌
유형 모호성으로 인해 이전에 작동하던 것이 이제 실패할 수 있습니다. 기본 유전학
함수에 대한 유형이 도움이 되지만 올바르게 수행하기는 매우 까다롭습니다.

2020년 6월 12일 금요일 21:21 negamartin [email protected] 에서 다음과 같이 썼습니다.

방금 #RFC 2870에 있는 lib 팀의 주석에서 작은 줄을 발견했습니다.
https://github.com/rust-lang/rfcs/pull/2369 :

가능성에는 일반화하여 메소드를 "오버로딩"하는 것이 포함될 수 있습니다.
또는 빌더 패턴.

여전히 허용하는 경우 메서드를 제네릭으로 만드는 것이 이전 버전과 호환됩니까?
이전 콘크리트 유형? 그렇다면 그것이 최선의 방법이 될 것이라고 믿습니다.
앞으로.

(빌더 패턴은 반복자에서 약간 직관적이지 않습니다.
반복자는 일반적으로 행동 변경자가 아니라 어댑터입니다. 게다가 있다
예를 들어, chunks와 chunks_exact는 별개의 두 가지입니다.
chunks().exact() 콤보가 아닌 메소드)

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/rust-lang/rust/issues/43244#issuecomment-643444213 ,
또는 구독 취소
https://github.com/notifications/unsubscribe-auth/AB2HJELPWXNXJMX2ZDA6F63RWJ53FANCNFSM4DTDLGPA
.

이전의 구체적인 유형을 여전히 수락하는 경우 메서드를 제네릭으로 만드는 것이 이전 버전과 호환됩니까? 그렇다면 그것이 최선의 길이라고 생각합니다.

아니요, 어떤 경우에는 유형 추론이 중단되기 때문입니다. 예를 들어 foo.method(bar.into()) 는 구체적인 유형 인수와 함께 작동하지만 일반 인수에서는 작동하지 않습니다.

지금 구현된 drain_filter는 매우 유용하다고 생각합니다. 이대로 안정될 수 있을까? 미래에 더 나은 추상화가 발견된다면, 그것들이 도입되는 것을 막을 수 있는 것은 없습니다.

drain_filter() 와 상관없이 retain_mut() 추가를 시도하려면 어떤 프로세스를 시작해야 합니까? 요구 사항이 다양하고 drain_filter() 에 무슨 일이 일어나든 retain_mut() 는 여전히 유용할 것 같습니다.

새로운 불안정한 라이브러리 API에 대한 @BartMassey , 구현으로 PR을 만드는 것이 좋을 것이라고 생각합니다. 기능 구현에 대한 지침은 https://rustc-dev-guide.rust-lang.org/implementing_new_features.html 및 https://rustc-dev-guide.rust-lang.org/getting-started.html 에 있습니다. 변경 사항을 테스트하기 위한

저는 오늘 HashMap 과 BTreeMap 사이의 API 차이로 인해 어려움을 겪었고, 다양한 컬렉션이 만들 때마다 일관된 API를 유지하기 위해 노력하는 것이 중요하다고 생각한다는 주의 사항을 공유하고 싶었습니다. 의미, 이 시점에서 항상 그런 것은 아닙니다.

예를 들어 String, Vec, HashMap, HashSet, BinaryHeap 및 VecDeque에는 retain 메서드가 있지만 LinkedList 및 BTreeMap에는 없습니다. retain 는 임의 삭제가 매우 비용이 많이 드는 작업인 벡터보다 LinkedList 또는 Map에 대해 더 자연스러운 방법으로 보이기 때문에 특히 이상합니다.

그리고 좀 더 깊이 파고들면 훨씬 더 복잡합니다. HashMap::retain 의 클로저는 변경 가능한 참조의 값을 전달하지만 다른 컬렉션은 변경할 수 없는 참조를 얻습니다(String은 간단한 char ).

이제 drain_filter 와 같은 새 API가 추가되고 있음을 알 수 있습니다. 1/은 retain 와 겹치고 2/는 모든 컬렉션에 대해 동시에 안정화되지 않습니다.

• HashMap::drain_filter 는 업스트림 저장소에 있지만 아직 Rust의 std AFAIK와 함께 제공되지 않습니다(문서에는 표시되지 않음)
• BTreeMap::drain_filter , Vec::drain_filter , LinkedList::drain_filter 는 Rust의 표준에 있지만 기능이 제한됩니다.
• VecDeque::drain_filter 은(는) 전혀 존재하지 않는 것으로 보이며 문서에 나타나지 않습니다.
• String::drain_filter 도 존재하지 않습니다

이러한 기능을 구현하는 가장 좋은 방법에 대한 강력한 의견이 없거나 drain_filter , retain 또는 둘 모두가 필요한 경우 이러한 API가 컬렉션 전체에서 일관성을 유지해야 한다고 매우 강력하게 믿습니다. .

그리고 아마도 더 중요한 것은 서로 다른 컬렉션의 유사한 메서드가 동일한 의미를 가져야 한다는 것입니다. retain 의 현재 구현이 IMO를 위반하는 것입니다.