Size: a a a

2020 May 09
Блог*
#prog #rust

Хозяйке на заметку

Если вы когда-нибудь писали на Rust какую-нибудь рекурсивную структуру, то у вас там наверняка было поле вроде Option<Box<Self>> или Option<Rc<Self>>. Для обхода подобной структуры требуется получить ссылку из поля такого типа. В принципе, можно писать что-то вроде

if let Some(relative) = &self.relative {
   // здесь можно работать с relative как с &Self благодаря deref coercion
}

, но если по каким-то причинам требуется Option<&Self>, то это уже не сработает из-за несовпадения типов. Приведение типов в подобной ситуации выглядит как field.as_ref().map(<_>::deref), или того хуже, field.as_ref().map(|x| &**x). Как я недавно с некоторым удивлением для себя обнаружил, это достаточно распространённый паттерн, чтобы для него были отдельные методы: Option::as_deref и Option::as_deref_mut. Что они делают — очевидно по типам:
fn as_deref(&self) -> Option<&<T as Deref>::Target>;
fn as_deref_mut(&mut self) -> Option<&mut <T as Deref>::Target>;

Есть резон не использовать эти методы? Если у вас стоит задача поддерживать старые версии rustc, то да, есть: эти методы были добавлены в Rust 1.40.0 (видимо, по этой причине я раньше про них и не знал). Конечно, ничто не мешает написать extension trait для добавления этих методов, только имейте в виду: если одно и то же выражение может быть как вызовом собственного метода типа, так и вызовом метода трейта, то предпочтение всегда отдаётся собственному методу типа.
источник
Блог*
dereference_pointer_there
#prog #rust

Хозяйке на заметку

Если вы когда-нибудь писали на Rust какую-нибудь рекурсивную структуру, то у вас там наверняка было поле вроде Option<Box<Self>> или Option<Rc<Self>>. Для обхода подобной структуры требуется получить ссылку из поля такого типа. В принципе, можно писать что-то вроде

if let Some(relative) = &self.relative {
   // здесь можно работать с relative как с &Self благодаря deref coercion
}

, но если по каким-то причинам требуется Option<&Self>, то это уже не сработает из-за несовпадения типов. Приведение типов в подобной ситуации выглядит как field.as_ref().map(<_>::deref), или того хуже, field.as_ref().map(|x| &**x). Как я недавно с некоторым удивлением для себя обнаружил, это достаточно распространённый паттерн, чтобы для него были отдельные методы: Option::as_deref и Option::as_deref_mut. Что они делают — очевидно по типам:
fn as_deref(&self) -> Option<&<T as Deref>::Target>;
fn as_deref_mut(&mut self) -> Option<&mut <T as Deref>::Target>;

Есть резон не использовать эти методы? Если у вас стоит задача поддерживать старые версии rustc, то да, есть: эти методы были добавлены в Rust 1.40.0 (видимо, по этой причине я раньше про них и не знал). Конечно, ничто не мешает написать extension trait для добавления этих методов, только имейте в виду: если одно и то же выражение может быть как вызовом собственного метода типа, так и вызовом метода трейта, то предпочтение всегда отдаётся собственному методу типа.
Как подсказывает @ihatereality, есть также методы Result::as_deref{, _mut}{, _err}.
источник
Блог*
#prog #rust #meme
источник
Блог*
источник
2020 May 12
Блог*
Как сказать "нет" $SUBJECT

https://www.starterstory.com/how-to-say-no
источник
Блог*
#prog #meme (thanks @pavver)
источник
Блог*
#prog #c #cpp #article

Так как регулярно возникает странное мнение, что UB — это не страшно, вот статья с примером, как UB может привести к вызову никогда не вызываемой функции. Old but gold, как говорится.

https://kristerw.blogspot.com/2017/09/why-undefined-behavior-may-call-never.html
источник
2020 May 13
Блог*
#prog #rust #quotes
источник
Блог*
Переслано от codingteam@cjr
Minoru
о! Кстати! В продолжение дискуссии про макру python!, встраивающую Python в Rust: это же фактически реализация принципа «язык под задачу». Просто выбираешь, что тебе удобнее написать на Rust, а что на Python…
источник
Блог*
dereference_pointer_there
Переслано от codingteam@cjr
Minoru
о! Кстати! В продолжение дискуссии про макру python!, встраивающую Python в Rust: это же фактически реализация принципа «язык под задачу». Просто выбираешь, что тебе удобнее написать на Rust, а что на Python…
#prog #rust #python #article

Насколько далеко можно зайти в поддержке кода на Python внутри Rust? Достаточно далеко, чтобы заставить IDE подсвечивать ошибки в коде на Python.

https://blog.m-ou.se/writing-python-inside-rust-3/
источник
Блог*
dereference_pointer_there
#prog #rust #python #article

Насколько далеко можно зайти в поддержке кода на Python внутри Rust? Достаточно далеко, чтобы заставить IDE подсвечивать ошибки в коде на Python.

https://blog.m-ou.se/writing-python-inside-rust-3/
Собственно
источник
Блог*
dereference_pointer_there
#prog #article

As closing thoughts: this blog post is not intended to start a flame war, nor is it intended to be an assault on dynamically typed programming. There are many patterns in dynamically-typed languages that are genuinely difficult to translate into a statically-typed context, and I think discussions of those patterns can be productive. The purpose of this blog post is to clarify why one particular discussion is not productive, so please: stop making these arguments. There are much more productive conversations to have about typing than this.

https://lexi-lambda.github.io/blog/2020/01/19/no-dynamic-type-systems-are-not-inherently-more-open/
#prog #article

Своеобразное продолжение статьи, даром что автор другой.

"One day you open that module which you haven’t touched in six months, and you see a function call where the third argument is null. You need to remember what kinds of variables you can pass to that third argument, or read the whole source code to figure it out. You follow through the code to see all places that third argument is used and realize the accepted type of the third argument depends on what you give to the second argument. Congratulations, you’re dealing with a dependent type, which means you’ve just surpassed Haskell in terms of type system complexity. Compilers that deal with this kind of type system are so complex they are effectively proof assistants (and are at the forefront of programming language research), and here you are dealing with those data types with your brain (and your faith in your ability to come up with sufficient tests) alone."

https://hisham.hm/2020/01/20/dynamic-type-systems-arent-even-simpler/
источник
Блог*
#rust

Небольшое напоминание (главным образом новичкам, но и остальным тоже): если вы работаете в Rust с текстом в ASCII — пожалуйста, не используйте коды символов напрямую. Для ASCII в Rust есть прекрасные инструменты —  байтовые литералы.

b'A' — это литерал типа u8, имеющий значение 65, но это куда понятнее, чем 65.

Также есть ещё и литералы для байтовых массивов:

assert_eq!(b"hello", &[104, 101, 108, 108, 111]);

Обратите внимание, это именно (статичная) ссылка на массив. Если вам нужно куда-то передавать байтовый слайс, то, возможно, придётся приводит к слайсу явно: &b"hello"[..].
источник
2020 May 14
Блог*
Главный герой - простой австрийский художник, которого по непонятным причинам пытаются убить путешественники во времени.
источник
Блог*
😭
источник
Блог*
источник
2020 May 15
Блог*
Q: When I was 4, my sister was 2. I am now 44. How old is my sister?

Programmer: 44 - (4 - 2) = 42

Tester:
источник
Блог*
источник
2020 May 16
Блог*
Дорогие мои подписчики, я вынужден просить вас о помощи. Пожалуйста, свяжитесь со мной, кто занимался на Rust численными методами решения диффуров.

Писать лучше в @decltype_chat_ptr_t, потому что сообщение в личку я могу банально потерять среди всех моих чатов и каналов
источник
Блог*
#prog #rust #meme
источник