> Quite a few of my programming adventures start with “this sounds impossible, let’s do it!"

(C) Mara: Writing Python inside your Rust code — Part 1A

У меня тоже самое =)

У каждого программиста на расте наступает такой момент, когда он открывает что-то вроде и очевидное, но неожиданное.

Среди такого можно отметить например .collect::<Result<Vec<_>, _>> или упомянутые в статье ниже Option::as_deref{,_mut} (ну и Result::as_deref{,_mut}{,_err})

Много таких приятных штук в std :)

#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 для добавления этих методов, только имейте в виду: если одно и то же выражение может быть как вызовом собственного метода типа, так и вызовом метода трейта, то предпочтение всегда отдаётся собственному методу типа.

Хм, тут появилась идея сделать очень очень очень маленький крейтик, чтобы

1. накостылять решение проблемы с PhantomData<fn(T) -> T> которую нельзя создать в const fn [^1]

2. сделать код более читаемым, именую непонятные типы

Упрощённо идея такая:

type Invariant<T> = PhantomData<fn(T) -> T>;
type Covariant<T> = PhantomData<fn() -> T>;
type Contravariant<T> = PhantomData<fn(T) -> ()>;

(+ дока с объяснениями и хак для const fn)

Что думаете?

Собственно при написании typed_phy мне чего-то такого не хватало, поэтому и задумался

(reddit)

Вот знаете, иногда смотрите на что-то (слово например), что видели много раз, и вдруг понимаете почему так...

Я только что понял что lt и gt это less than и greater than (вафель 17 годиков)

Нам нужна большая поставка типов 😂😂😂

не можешь зайти, потому что пароль не подходит
@
меняешь пароль
@

Как ты сайт назовёшь, так он и задеплоится (С)

Не знаю давно ли, но в гитхабе появились автосвязывающиеся ссылки "Autolink references". Можно указать любой префикс (например tg/) и формат ссылки (например t.me/ihatereality/<num>), после этого любой текст вида preifx<num> (например tg/775) в issue/pr/etc будут автоматически превращены в ссылки.

Полезно например чтобы свой todo-list прикрутить и легко на него ссылаться.

Идея классная, жалко что кроме параметра <num> никак нельзя кастомизировать(

>_<