Size: a a a

2020 April 18
Блог*
Так, а что тут не так? И почему не совпадают типы?

Дело в том, что у каждой функции — не только у замыканий — в Rust свой собственный уникальный тип. Здесь мы попытались сохранить значения двух разных типов в паре одинаковых типов, поэтому наш код не компилируется.

Зачем так сложно? В этом же нет никакого смысла!

Вообще-то есть. Компилятор эксплуатирует тот факт, что тип населён единственным значением, и потому не хранит и не передаёт адрес функции, а вставляет его по месту вызова. Таким образом, компилятору предоставляется больше возможностей для встраивания (inlining) функций. Также это влияет на структуры, которые хранят в себе функции: если тип не указан явно как функциональный указатель, обычная функция вообще не занимает места в памяти. Функциональный указатель же занимает столько же места, сколько и указатель:

fn main() {
   assert_eq!(std::mem::size_of_val(&add_one), 0);
   let add_one_ptr: fn(u32) -> u32 = add_one;
   assert_eq!(
       std::mem::size_of_val(&add_one_ptr),
       std::mem::size_of::<usize>()
   );
}

Кстати, на замыкания это тоже распространяется: значение замыкания хранит в себе только захваченные данные, поэтому размер замыкания равен (с поправкой на выравнивание) размеру захваченных данных. Если замыкание ничего не захватывает, то у него нулевой размер:

fn main() {
   assert_eq!(std::mem::size_of_val(&|x: u32| x + 1), 0);
}

Теперь я вижу, что в этом действительно есть смысл. И всё-таки, как скомпилировать тот пример с парой функций?

Просто хранить разнородную пару.

А если нам принципиально, чтобы элементы пары имели одинаковый тип?

В таком случае нам надо привести значения к одинаковому типу. Это можно сделать так:

let funcs: Pair<fn(_) -> _> = (add_one, add_two);

Обратите внимание, выписывать тип точно в этом случае не нужно, достаточно сказать, что это function pointer. Другой способ — явно привести одно из значений в паре:

let funcs: Pair<_> = (add_one as fn(_) -> _, add_two);

Второе значение будет неявно приведено (coerced) к нужному типу. В принципе, ничто не мешает написать явный каст у обоих значений, но надобности в этом в данном примере нет. Кстати, если мы сделаем массив функций, то никаких кастов делать не придётся, rustc сам уравняет типы до функционального указателя:

let arr = [add_one, add_two];

А что, если замыкание возвращает захваченное значение? Если это значение не копируемо, то замыкание можно вызвать только один раз...

А вот про это я расскажу в следующий раз.
источник
Блог*
Это... Это просто великолепно.

https://youtu.be/y8OnoxKotPQ
источник
Блог*
#prog #amazingopensource

Если вы когда-нибудь хотели сделать свой блог, но не знали, как сделать комментарии (или не хотели подключать жирный Disqus), то этот вариант может подойти: комментарии, работающие поверх issue в GitHub.

utteranc.es
источник
Блог*
Помогите коллеге, пожалуйста
источник
Блог*
Есть некоторое http-api. Я пишу для него враппер на расте. В апи один из параметров метода — число от 1 до 100000. Вопрос: как лучше отобразить отобразить этот параметр в либе?
Окончательные результаты
27%
u32
3%
NonZeroU32
63%
new-type который будет проверять что он >= 1 && <= 100000
8%
(свой вариант)
Проголосовало: 78
источник
2020 April 19
Блог*
#prog #meme

Очень точно
источник
Блог*
источник
Блог*
#blogrecommendation

Человек пишет на Rust... Много всего. В частности, недетерминированный парсер для естественного языка — и это его
дипломная работа. Если честно, я даже немного завидую его продуктивности.

t.me/optozorax_dev/184
Telegram
dev optozorax
А мой парсер всё обрастает возможностями. Теперь можно задавать как будут изменяться "вероятности" распаршенного правила.

UPD: это скорее не вероятности, а веса.

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

Например, можно уменьшать вероятность для синонимов.

Возьмём за основу такое правило:

P -> b? c d* e | c c;

И добавим к нему вероятностей вместе с записью в json:
P -> ("b" 20%+)? "c" ("d" 5%-)* "e" 60% | "c" "c" { parsed.rule = "p"; };

Конструкция 20%+ означает, что к вероятности прибавится 20% (домножение на 1.2). 5%- делает аналогично, но в обратную сторону (домножение на 0.95). Проценты без всяких знаков, обозначают просто вероятность самого правила. Если проценты не написаны, это означает что написано 100%.

Так же, если подумать, вероятности - это одна из разновидностей действий, которые выполняются, если что-то распарсилось, причём рекурсивно для всех подправил распаршенного. А действия…
источник
2020 April 20
Блог*
Чудесный #rust #meme от @DogeShibu
источник
Блог*
Переслано от Doge Shibu
Я и тайп-левел программирование на расте
источник
Блог*
Звуки распила

habr.com/ru/news/t/498048/
источник
Блог*
#prog #rust #meme
источник
Блог*
источник
2020 April 21
Блог*
#quotes
источник
Блог*
Переслано от red75prime
unsafe не значит, что там что-то не так. Это значит, что мы знаем что-то, что не знает компилятор. Или думаем, что знаем
источник
Блог*
#prog #article

Реальность такова, что среди существующих программ полно уязвимых, допускающих использование в злонамеренных целях. Огромное количество подобных уязвимостей проистекает из некорректного парсинга входных данных. Конечно, легко сказать: "Эй, программисты, будьте внимательнее", но практика показывает, что подобный метод работает довольно фигово. В данной статье перечислены основные проблемы, возникающие при обработке входных данных, вместе с более-менее конкретными указаниями на то, как их исправить.

http://langsec.org/papers/langsec-cwes-secdev2016.pdf
источник
Блог*
#prog #rust

Недавно в Rust-сообществе поднялся шум по поводу недавней статьи лодочника WithoutBoats, в которой он приводит аргументы за автоматическое оборачивание в Ok значений, возвращаемых из функций с типом возврата Result. В ней представлены несколько аргументов "за" различной степени убедительности и опровергнуты несколько откровенно слабых аргументов "против". Один из ответов на эту статью — Mental models about Ok-Wrapping, в которой приведены реальные сложности, которые могут возникнуть с на практике с подобной реализацией.
источник
2020 April 24
Блог*
Ага, что это тут у нас? 300 подписчиков! 🎉🎉🎉
источник
Блог*
источник
2020 April 25
Блог*
Всем известно, что антиква (шрифты с засечками) читается лучше, чем гротеск (шрифты без засечек). Ведь так? Так?

Ну, не совсем. Или даже совсем не. Разбирается на хабре Юлия Кондратьева.

habr.com/ru/company/tinkoff/blog/498878/

#article и пусть будет новый хештег, скажем... #design
источник