Да вот как раз для отсутствия дурацких споров на каждом проекте или в каждой компании один раз решили и встроили в компилятор. Но видимо некоторые всё ещё считают, что надо что-то переиграть в стайлгайде.
К слову, зачем? В других крейтах вы стиль на нужный вам не поменяете в любом случае, поэтому в итоге будет мешанина из вашего стиля наименования и стандартного.
#[unsafe(no_mangle)] просто выключает name mangling для данной функции. Никакого unsafe контекста на весь код тут нет.
Трансляцию можно посмотреть с помощью какого-нибудь cargo-asm, но, если честно, не совсем уверен, что вы хотите там увидеть - при сборке с оптимизацией вызова Arkanoid::new() там просто нет.
Не знаю о каком недоверии к ассемблерным вставкам вы говорите - просто писать их принято осторожнее, чем весь остальной код, поскольку стандартная для обычного кода подстраховка от компилятора тут не работает.
Потому что можно потом погрепать "unsafe" и найти все места, где UB вообще имеет шанс случиться. Поскольку за пределами этого блока UB не должно быть возможно по определению. Говорят, что при ревью довольно удобно.
Так "nop" на это и не способен, но содержимое asm! в общем случае вполне может что-то не то сделать, если его не так написать. Поскольку компилятор не может отличить первый случай от второго (да и невозможно благодаря проблеме останова), unsafe {} необходимо ставить при любом использовании asm!. И известно безопасные использования asm! оборачивать в безопасные функции (почему в данном случае автор этого не сделал для inb - для меня загадка).
Блок unsafe {} вокруг asm! как раз нужен, поскольку это одна из тех вещей, которой потенциально можно вызвать UB, и вне блока unsafe использовать asm! просто не получится.
Учитывая, что тут нет никаких вариантов вызова UB с помощью данной функции, то unsafe fn вполне могла бы быть обычной функцией.
Ничего подобного - unsafe {} только разрешает выполнять вещи, которыми потенциально можно устроить UB, а unsafe fn обозначает, что у функции есть какие-то не проверяемые компилятором требования, которые для вызова функции нужно соблюсти, и следовательно вызывать её нужно в блоке unsafe. Никакого дополнительного связанного с переупорядочиванием и прочим изменением семантики кода у unsafe поведения нет.
Из примечательного - unsafe fn имеет внутри себя неявный unsafe {} блок, но в последних версиях компилятора отсутствие явного unsafe {} кидает предупреждение.
С подтипами как-то поорганизованнее получается ИМХО. К примеру: вот куда складывать документацию о том, какой именно формат ожидается от переменной user_phone_number? Если это новый тип вокруг строки, то всё довольно понятно - это идёт в докстринг к типу, со всеми прилагающимися удобвствами вроде работы IntelliSense с ней.
findImageByUserId вообще можно сделать методом UserId, тогда узнать о существовании этой функции как таковой будет проще.
По части подтипов в стандартных типов: файловые пути на первый взгляд просто текст, но в последнее время их делают подтипами байтовых массивов. Примеры можно найти в Python (pathlib.Path), c++ (std::filesystem::path), Rust (std::path::PathBuf).
Тут вы правы, обычный итератор так разбить не получится, как минимум потому что никто не запрещает ему вернуть ссылку на один и тот же элемент дважды подряд, что сразу нарушит правило "только одна &mut ссылка на каждый объект".
Как минимум 90%, причём в основном видео с ютуба и, наверно, торренты. А ведь ещё есть куча всякого «бесполезного» трафика от мультиплеера в играх. Проще сказать какой процент нешифрованного текстового трафика — 0.1% максимум.
Да вот как раз для отсутствия дурацких споров на каждом проекте или в каждой компании один раз решили и встроили в компилятор. Но видимо некоторые всё ещё считают, что надо что-то переиграть в стайлгайде.
К слову, зачем? В других крейтах вы стиль на нужный вам не поменяете в любом случае, поэтому в итоге будет мешанина из вашего стиля наименования и стандартного.
Поляна готовиться отдельным пакетом bootloader, а собирается это всё в образ с помощью bootimage.
#[unsafe(no_mangle)] просто выключает name mangling для данной функции. Никакого unsafe контекста на весь код тут нет.
Трансляцию можно посмотреть с помощью какого-нибудь cargo-asm, но, если честно, не совсем уверен, что вы хотите там увидеть - при сборке с оптимизацией вызова Arkanoid::new() там просто нет.
Не знаю о каком недоверии к ассемблерным вставкам вы говорите - просто писать их принято осторожнее, чем весь остальной код, поскольку стандартная для обычного кода подстраховка от компилятора тут не работает.
Потому что можно потом погрепать "unsafe" и найти все места, где UB вообще имеет шанс случиться. Поскольку за пределами этого блока UB не должно быть возможно по определению. Говорят, что при ревью довольно удобно.
Так "nop" на это и не способен, но содержимое asm! в общем случае вполне может что-то не то сделать, если его не так написать. Поскольку компилятор не может отличить первый случай от второго (да и невозможно благодаря проблеме останова), unsafe {} необходимо ставить при любом использовании asm!. И известно безопасные использования asm! оборачивать в безопасные функции (почему в данном случае автор этого не сделал для inb - для меня загадка).
Блок unsafe {} вокруг asm! как раз нужен, поскольку это одна из тех вещей, которой потенциально можно вызвать UB, и вне блока unsafe использовать asm! просто не получится.
Учитывая, что тут нет никаких вариантов вызова UB с помощью данной функции, то unsafe fn вполне могла бы быть обычной функцией.
Ничего подобного - unsafe {} только разрешает выполнять вещи, которыми потенциально можно устроить UB, а unsafe fn обозначает, что у функции есть какие-то не проверяемые компилятором требования, которые для вызова функции нужно соблюсти, и следовательно вызывать её нужно в блоке unsafe. Никакого дополнительного связанного с переупорядочиванием и прочим изменением семантики кода у unsafe поведения нет.
Из примечательного - unsafe fn имеет внутри себя неявный unsafe {} блок, но в последних версиях компилятора отсутствие явного unsafe {} кидает предупреждение.
С подтипами как-то поорганизованнее получается ИМХО. К примеру: вот куда складывать документацию о том, какой именно формат ожидается от переменной user_phone_number? Если это новый тип вокруг строки, то всё довольно понятно - это идёт в докстринг к типу, со всеми прилагающимися удобвствами вроде работы IntelliSense с ней.
findImageByUserId вообще можно сделать методом UserId, тогда узнать о существовании этой функции как таковой будет проще.
По части подтипов в стандартных типов: файловые пути на первый взгляд просто текст, но в последнее время их делают подтипами байтовых массивов. Примеры можно найти в Python (pathlib.Path), c++ (std::filesystem::path), Rust (std::path::PathBuf).
Тут вы правы, обычный итератор так разбить не получится, как минимум потому что никто не запрещает ему вернуть ссылку на один и тот же элемент дважды подряд, что сразу нарушит правило "только одна &mut ссылка на каждый объект".
С помощью rayon можно сделать так: playground
Это, конечно, не делает явное партиционирование, но вполне честно распарралеливает обработку.
В том же расте у итераторов есть дополнительные методы, такой универсальный диапазон можно организовать с помощью
.skip(a).take(b).