вы мне лучше объясните вот это

Alex@ZPC MINGW64 ~/Documents/Rust/boyan_detector_bot (feature/mutiple_chats) $ cargo fmt error: toolchain 'nightly-2018-06-28-x86_64-pc-windows-gnu' does not have the binary `cargo-fmt.exe` Alex@ZPC MINGW64 ~/Documents/Rust/boyan_detector_bot (feature/mutiple_chats) $ cargo --version cargo 1.29.0-nightly (2cd36b4ed 2018-07-25) Alex@ZPC MINGW64 ~/Documents/Rust/boyan_detector_bot (feature/mutiple_chats) $ rustup component add rustfmt-preview --toolchain nightly-x86_64-pc-windows-gnu info: component 'rustfmt-preview' for target 'x86_64-pc-windows-gnu' is up to date

Alex@ZPC MINGW64 ~/Documents/Rust/boyan_detector_bot (feature/mutiple_chats) $ cargo fmt error: toolchain 'nightly-2018-06-28-x86_64-pc-windows-gnu' does not have the binary `cargo-fmt.exe` Alex@ZPC MINGW64 ~/Documents/Rust/boyan_detector_bot (feature/mutiple_chats) $ cargo --version cargo 1.29.0-nightly (2cd36b4ed 2018-07-25) Alex@ZPC MINGW64 ~/Documents/Rust/boyan_detector_bot (feature/mutiple_chats) $ rustup component add rustfmt-preview --toolchain nightly-x86_64-pc-windows-gnu info: component 'rustfmt-preview' for target 'x86_64-pc-windows-gnu' is up to date

в тулчейн не положили cargo-fmt (посколько он вероятно был сломан, когда собирали тулчейн), обычное дело

он с какого-то хуя собирает под 06-28

в тулчейн не положили cargo-fmt (посколько он вероятно был сломан, когда собирали тулчейн), обычное дело

он не должен под него собирать

он должен на последнем найтли собирать

тулчейн-файла нет

а сука

$ rustup toolchain list stable-x86_64-pc-windows-gnu nightly-2018-06-28-x86_64-pc-windows-gnu (default) nightly-2018-06-28-x86_64-pc-windows-msvc nightly-2018-07-24-x86_64-pc-windows-msvc nightly-x86_64-pc-windows-gnu

понятно

обновил компилятор - дефолт сбрсоился

warning: it is more idiomatic to loop over references to containers instead of u sing explicit iteration methods --> imagedb\src\lib.rs:104:43 | 104 | for &(ref image, ref metadata) in self.images.iter() { | ^^^^^^^^^^^^^^^^^^ help: to writ e this more concisely, try: `&self.images` | = note: #[warn(explicit_iter_loop)] on by default = help: for further information visit https://rust-lang-nursery.github.io/ru st-clippy/v0.0.212/index.html#explicit_iter_loop

хмм

тут кто-то затирал, что лучше iter или мне кажется?

оооо, так в клиппи этого нет, потому что это завезли в компилятор!

а блин, это и есть клиппи

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

чет он тупой какой-то

предлагает Default который уже есть

предлагает Default который уже есть

похоже с дженериками не справляется

да

я сначала подумал что ему констрейнт не нравится

но он просто с ними не дружит

лол, если вручную заимплементить Default, то варнинга нет

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

тебе уже кстати говорили, что добавлять ограничения на дженерики при объявлении типа — моветон?

нет

я не люблю where если там не километровое определение

причём здесь where?

тогда о чем речь?

про generic bound при объявлении типа

struct Lol<Wut: Debug> { ... }

ну то есть иногда это оправдано, особенно если ты юзаешь associated types из баунда, но обычно — нафиг не нужно

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

ты изменил код, или у меня галлюцинации, и у тебя там с самого начала было #![allow(unused)] ???

ну то есть иногда это оправдано, особенно если ты юзаешь associated types из баунда, но обычно — нафиг не нужно

прикольное у тебя "обычно"

Debug требовать может быть странно, но в целом зависит же от того что за типа у тебя и чо за баунды

Debug требовать может быть странно, но в целом зависит же от того что за типа у тебя и чо за баунды

тебе же так и так надо будет этот баунд указывать в блоке impl

это, кстати, бесит; могли бы по умолчанию брать из структурки

но ок, твой пойнт — саму структурку держать чистой, а баунды только в импл? и чо так часто делают?

ты изменил код, или у меня галлюцинации, и у тебя там с самого начала было #![allow(unused)] ???

не было, я добавил, чтобы лишние ворнинги не мешались

ну то есть иногда это оправдано, особенно если ты юзаешь associated types из баунда, но обычно — нафиг не нужно

а как ты по-другому сделаешь?

но ок, твой пойнт — саму структурку держать чистой, а баунды только в импл? и чо так часто делают?

угу, https://users.rust-lang.org/t/should-i-put-where-bounds-on-the-struct-or-on-the-impl/7064/4 , где-то был более развёрнутый ответ, но чё-т не гуглится

если у тебя есть ограничение на структуре

ты должен везде совать

если у тебя есть ограничение на структуре

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

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

но это так и есть

но это так и есть

ну в твоём случае с Clone, который ты убрал, это не "необходимо" =) тебе достаточно сделать баунд в impl-блоке, причём только для тех методов, где этот клон нужен

ну в твоём случае с Clone, который ты убрал, это не "необходимо" =) тебе достаточно сделать баунд в impl-блоке, причём только для тех методов, где этот клон нужен

да

для 100% методов

ну твоему методу new он не нужен, например :)

ага

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

можно создать объект, только с ним ничо сделаь нельзя

хз

мне кажется ты не совсем прав

ну такое, minor thing, конечно

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

то надо его делать на стурктуре

ну вот например https://doc.rust-lang.org/std/collections/struct.HashSet.html

угу, https://users.rust-lang.org/t/should-i-put-where-bounds-on-the-struct-or-on-the-impl/7064/4 , где-то был более развёрнутый ответ, но чё-т не гуглится

спасиб, норм пойнт — https://doc.rust-lang.org/src/std/collections/hash/map.rs.html#399 тут тож делают так

спасиб, норм пойнт — https://doc.rust-lang.org/src/std/collections/hash/map.rs.html#399 тут тож делают так

ога

а чот клиппи на меня не наорал за это %(

а чот клиппи на меня не наорал за это %(

ну это имхо слишком minor issue + ему, вероятно, будет сложно понять, нужен ли тебе этот баунд реально в структурке или таки нет

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

а для конкретных реализовывать дополнительный функционал

но в моем случае для любых типов не реализующих трейт структура бесполезная

Чёт спор про монорепы поутих

Но я отмечу, что есть промежуточный вариант — монорепа с крейтами, а они друг от друга по версиям уже.

Ну, подход lerna и прочих

С одной стороны нет хуйни, когда из одной части кода хер пойми что импортируется (а это дело очень любят, удобненько же). С другой, не надо заводить дублирующие ПРы, если репы однотипные (скажем, проекты одинаковые параллельно делаются и надо везде что-то добавить)

Но подход больше для развесистых либ, вроде serde или babel-я, нежели для проектов

Но подход больше для развесистых либ, вроде serde или babel-я, нежели для проектов

пропустил слово "игрушечных")

второй-то не игрушечный)

Но я отмечу, что есть промежуточный вариант — монорепа с крейтами, а они друг от друга по версиям уже.

Ну про такой речь и шла, никто не говорит все складывать в один крейт, разные папки-разные файлы. Удобнее фиксить в случае смены апи, на начальных этапах

А

Ну это просто не совсем то, что понимают под "монорепой" в, например, яндексе

А там чё за говно? Просто думал что в контексте раста ток так

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

чяднт