не ту пасту открыл

А если через итераторы?

Ага. Если что, это пример написанный по куску реального кода, просто демонстрация Переписать на итераторах нельзя, надо обходить

nll раздражает, что фолспозитивит варнинги на ненужную мутабельность

Ладн, все равно к этому всё шло. Сделаю фич-гейт nightly на либу и включу nll на найтли

На стейбле путь будет double-get

Так чо на итераторах нельзя? Enumerate и filter-map не справляются?

так а что не так с v.iter_mut().find(|&&mut value| value == key) ?

Ну я не знаю что ещё такого в for чего нет в iter. Вот и предположил.

https://play.rust-lang.org/?gist=8a4acee95df38bf4cae22ba470b8f0e3&version=stable&mode=debug

два гета

ваще можно unchecked get делать и норм

а v[i] это типа совсем не get )

это лучше, чем get.unwrap :)

ну... нет

то же самое

лучше не в плане производительности тот же clippy ругается на get.unwrap

я тоже не про производительность

перебирая i, ты не обойдёшься одним get

но ваще это какой-то жёсткий баг

бажина прям

return не делаешь, и всё компилится нормально

там выше уже написали, проблема с текущим борроучекером

делаешь return — приезжаешь

на нлл работает

да понятное дело

но всё равно обидно)

ну да)

но я все жду почему нельзя на итераторах

так а что не так с v.iter_mut().find(|&&mut value| value == key) ?

вроде то же поведение

но я все жду почему нельзя на итераторах

Или хотя бы на орлах

вариант

оно после первой итерации вернет

не, не то

ваще можно unchecked get делать и норм

Он и есть в реальном коде

ну тогда по идее оба гета — фактически бесплатные вызовы

@Renyare @nexmean двойной get не вариант, так и было изначально

ну тогда по идее оба гета — фактически бесплатные вызовы

Нет, за ними есть логика. Это вопрос не на как переписать пример кода, а как объяснить borrowck что он не прав

океей

ну походу никак :(

У меня там get ищет в бакете хешмапы, это далеко не бесплатно)

ну то есть всегда есть ансейф.. но.. :)

ну то есть всегда есть ансейф.. но.. :)

Ансейф не отключает borrowck :)

разве?

Ага

ну, всегда можно скатиться до поинтеров

Только если так

Но не, не хочу)

ну да, это перебор конечно

ты хочешь иммутабельную ссылку превратить в мутабельную, но в общем случае так нельзя делать, т.к. компилятор мог соптимизировать под немутабельность

ты хочешь иммутабельную ссылку превратить в мутабельную, но в общем случае так нельзя делать, т.к. компилятор мог соптимизировать под немутабельность

э?

ты хочешь иммутабельную ссылку превратить в мутабельную, но в общем случае так нельзя делать, т.к. компилятор мог соптимизировать под немутабельность

Где у меня иммутабельная ссылка?

в первом get

Нет, нету там ее

https://play.rust-lang.org/?gist=266f8da9b9ad391be7be67261745e455&version=stable&mode=debug

ты хочешь иммутабельную ссылку превратить в мутабельную, но в общем случае так нельзя делать, т.к. компилятор мог соптимизировать под немутабельность

он хочет по condition вернуть мутабельную ссылку на элемент

гитлаб или трэвис

drone)

можно наверное через mem::replace разрулить, хоть и некрасиво

https://play.rust-lang.org/?gist=266f8da9b9ad391be7be67261745e455&version=stable&mode=debug

https://play.rust-lang.org/?gist=c30de9138d9b1af45241af3f37a702e1&version=stable&mode=debug

ну всё равно же двойной гет

хотя мб .get() дешевле .get_mut()

вот чуть более понятная ошибка

Или так https://play.rust-lang.org/?gist=4a0365ce500fc4627c66d840f68fac46&version=stable&mode=debug

Да хоть тройной, компилятор выкинет лишние. Если там сайд эффектов нет от гета в реальном коде

сказали же, что двойной гет — не вариант

чё мусолить-то

Да хоть тройной, компилятор выкинет лишние. Если там сайд эффектов нет от гета в реальном коде

в смысле "выкинет"?

мутабельную ссылку нужно возвращать, куда он её выкинет

моя интерпретация того, что компилятор пытается сделать: пытается мутабельную ссылку сохранить в анонимной переменной и вернуть её после выхода из функции borrowck не позволяет это сделать, т.к. на новом шаге цикла мы повторно захватываем вектор

get и get_mut только на уровне типов различаются, v ты не миняешь в процессе, скорее всего значение полученное от get в итоге и вернётся из функции

get и get_mut только на уровне типов различаются, v ты не миняешь в процессе, скорее всего значение полученное от get в итоге и вернётся из функции

это какая-то особая магия?

llvm-оведы, призываю вас

borrowchk'а не существует на уровне llvm

я обратного не утверждал

я могу подискутировать насчёт того, что до Spectre процессор мог наперёд проверить условие, и просто вернуть второй гет, опуская первый но, кажется, мы в ближайшее время не вернёмся в эту прекрасную эпоху

ну чисто гипотетически llvm может понять, что там два раза подряд происходит ровно одно и то же (с точностью до мутабельности возвращаемого значения, но llvm на это пофиг должно быть), и оптимизировать всё это дело

но это совсем не факт

может сделать, может не сделать

и расчитывать на это я бы не стал

ну чисто гипотетически llvm может понять, что там два раза подряд происходит ровно одно и то же (с точностью до мутабельности возвращаемого значения, но llvm на это пофиг должно быть), и оптимизировать всё это дело

хз, я сильно не уверен

я тоже