Ведь такое можно сделать для SVec

для &SVec

это важно

Да, именно.

на самом деле странно, что нет такого: IntoIterator for &'a CheeseSlice<'a>

Вот да, я именно в поисках его и вглядывался в код soa

Соответственно и хз что делать.

ну, можно так делать: foobar(&vec); let slice = vec.as_slice(); foobar(slice.iter()); foobar(slice.iter());

Но опять же это делать за пределами трейта тогда надо руками всё время, что неудобно.

я думаю есть причина, по которой создатели soa-derive не запилили IntoIterator для &...Slice

https://github.com/inv2004/test_lifetimes/blob/master/src/main.rs

я думаю есть причина, по которой создатели soa-derive не запилили IntoIterator для &...Slice

Я спросил у них в гитхабе. Но туго продвигается простое написание цикла :)

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

наверное было бы проще, если бы ты сформулировал конечную задачу, потому что пока ты хочешь какой-то супер-мега-абстракции =)))

Да, но пока не видно что не так в данный момент.

Задача проста - есть структура с векторамт, хочу по ним интегрироваться и не писать бойлерплейт типа izip с кучей полей. + Есть вектора лежащие отдельно - те структура слайсов - я хочу их аналогично.

у тебя и вектор, и слайсы, уже всё имплементируют же

Пока вроде ничего поотеворечтвого с ходу не вижу в том чего хочу :)

берёшь и делаешь .into_iter().map() или что там угодно

какой бойлерплейт блин)

У меня структура которая итерирует и делает что надо : Pl в моём коде.

Pl - Player

у тебя принтскрин сломан?)))))

У меня рабочая машина не имеет доступа в телеграм.

эх

даже веб-клиент?

ну лан

https://github.com/inv2004/test_lifetimes/blob/master/src/main.rs

Но тут тоже самое.

даже веб-клиент?

Ага.

короче мой поинт такой, что Pl — не нужна, по крайней мере в том виде, что есть сейчас, потому что это просто лишний слой абстракции, который и так уже предоставляется итераторами

Нуу, надо подумать.

Задача проста - есть структура с векторамт, хочу по ним интегрироваться и не писать бойлерплейт типа izip с кучей полей. + Есть вектора лежащие отдельно - те структура слайсов - я хочу их аналогично.

это не задача, если что, это твой вариант её реализации

AB-problem, вот это вот всё )

ну, имхо конечно

Но если б был intoiter для &'sslice, то проблем бы не было. А почему его нет - хз

ну кроме того что у тебя уже супер-сложный код для такой простой задачи)

У меня в плеере как минимум ещё одна структура хранится. Конечно вероятно как-то можно извернуться. Но сейчас все вообще изи в бинарнике структура::new или new_slice. А дальше просто .play или each в данном случае. А иначе - итераторами наружу.

ну кроме того что у тебя уже супер-сложный код для такой простой задачи)

Так я наоборот хотел упростить именно в бинарнике, так как там будут появляться разные структуры и использовать один интерфейс по сути.

Т.е. очевидно вариант из new* возвращать просто SVec и SSlice и ходить по ним руками. Но получается что надо писать два разных обхода, и в одну функцию их не реализуешь - вот бойлерплейт получается кажется.

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

но

impl<'a> IntoIterator for &'a CheeseSlice<'a> { type Item = CheeseRef<'a>; type IntoIter = __detail_iter_cheese::Iter<'a>; fn into_iter(self) -> __detail_iter_cheese::Iter<'a> { self.iter() } }

даже наверное так лучше сделать объявление: fn into_iter(self) -> Self::IntoIter

https://gist.github.com/mexus/e9b70ac9c7b51878c7d00ec37a448a79

хотя чем &slice лучше slice.iter() я всё равно не понимаю

Ну тем что можно одинаково дёргать как и &vec

ну что значит одинакого

ты всё равно пишешь этот значок

и там, и там

и это разные типы

Да, спасибо, я как раз в эту сторону копал сейчас, но я так быстро не умею :)

не за что, это очень простая имплементация + __detail_iter_cheese::Iter — вот это жесть конечно

Но я же в конструктор .iter не могу передать.

но это разумеется надо добавлять в кодогенератор

что?)

Ну, может я не понял, сорян, но в твоём примере да - ты руками дергаешь всё - iter не проблема.

А у меня выше в коде там конструкторы - как там iter применить я что-то не соображу.

твой трейт вообще выглядит супер-странно

в нём по идее только fn test(&self) -> f32; должна быть, и всё

а уж как конструируют его экземляры — это-то пофигу же

Изначально были отдельные трейты, и в одним был только test. но я слил в один. Подумав, что почему бы и нет.

можете подсказать, как мне суметь использовать обращение к функции с разным количеством аргументов? https://play.rust-lang.org/?gist=141ee235d624f5b9fb10672fe3e1a6e9&version=stable

@NaviArh это просто — никак :) в расте нет function overloading

Вроде как оффициальная рекомендация - разные названия функций делать.

@inv2004 ну то есть класс Player у тебя должен уметь проигрывать пофигу что, так?

пофигу что, лишь бы это можно было каким-то образом итерировать и у этого что-то был бы метод test

@inv2004 ну то есть класс Player у тебя должен уметь проигрывать пофигу что, так?

Проигрывать то, что умеет .test и хранится в soa форме (последнее не уверен что могу точно утверждать)

ога

Могу как бы больше написать. Будут разные структуры типа S1, S2, и ТД с разным набором полей.

В обычном случае я описываю .new, которая там хитрым способом калькулирует S1Vec

И потом я хочу по этому набору данных прогнать и получить результат - всё норм.

Но иногда, для оптимизации подсчёта я использую одно из просчитанных полей старое, а перегенерб только для b например.

И тут вот и пришлось слайсы делать, а как иначе.

пожалуйста не надо называть их S1 и S2...

По сути что-то вроде оптимизации для gridsearch.

я понял, щас делаю прототип

пожалуйста не надо называть их S1 и S2...

Сорян. Kdb даёт о себе знать.

я понял, щас делаю прототип

Но вообще спасибо, я думаю реализация и сейчас в общем-то норм. И все что надо протащить в soa это изменение.

кстати, а почему бы всегда не использовать только слайсы?