В rust-analyzer changelog #114 есть и мой PR :')

#prog #rust

Это просто смешно

github.com/rust-lang/rust/issues/93514

(thanks @ihatereality)

В СМЫСЛЕ УЖЕ ФЕВРАЛЬ

Крутейшая новость для тех, кто любит читать пейперы (а именно препринты на arXiv). Если в ссылке на abstract статьи заменить "arxiv" на "ar5iv", то можно читать статью в виде веб-страницы. Тут больше деталей - https://twitter.com/dginev/status/1488157927001268231

Примеры статей:

https://arxiv.org/html/1504.00204 → https://ar5iv.org/html/1504.00204
https://arxiv.org/html/2102.02527 → https://ar5iv.org/html/2102.02527

#prog #rust #meme

#prog #rust #meme

inspired by @ekuber

#prog #rust

Очень хороший пример применения паттерна typestate.

twitter.com/bloomofthehours/status/1488464978852163589

(thanks @ihatereality)

#prog #rust #article

a design for simple interners

(thanks @ihatereality)

😒🤚 Бёрдвотчинг
😏👉 Порнвотчинг

Предлагаю запретить на paperswithcode считать код на матлабе за код.

#prog #java #article

Java’s Checked Exceptions Are Just Weird Union Types

(thanks @oleg_log)

#prog #rust

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

Иногда требуется писать реализации трейтов вроде PartialEq и Hash, для которых код не укладывается в прямолинейную схему derive-макросов. Например, в коде должны использоваться не непосредственно значения полей, а некоторая их комбинация, или же одно из полей должно быть проигнорировано при сравнении. Для того, чтобы разговор был более конкретным, покажем конкретный тип:

struct Big {
field: u32,
another: Vec<u8>,
one_more: (i32, i32),
irrelevant: String,
}

Напишем для этого типа реализацию PartialEq, которая будет игнорировать поле irrelevant. Казалось бы, всё просто:

impl PartialEq for Big {
fn eq(&self, rhs: &Self) -> bool {
self.field == rhs.field
&& self.another == rhs.another
&& self.one_more == rhs.one_more
}
}

Однако тут есть тонкий момент: если в структуру буду добавлены новые поля, то нужно будет не забыть дописать их сравнение в реализацию — и компилятор нам тут никак не поможет. Более того, исключения сравнения одного поля для программиста выглядит, как ошибка, и без поясняющего комментария следующий программист может "исправить" код и нарушить его логику.

Но мы можем написать код так, чтобы компилятор таки помогал! Первый способ — это сделать newtype, который будет в реализации PartialEq::eq безусловно возвращать true:

struct UnconditionallyEqual<T>(T);

impl<T> PartialEq for UnconditionallyEqual<T> {
fn eq(&self, _other: &Self) -> bool {
true
}
}

В этом случае достаточно поменять тип поля irrelevant на UnconditionallyEqual<String> — и можно будет использовать стандартный #[derive(PartialEq)] для достижения требуемого функционала. Бонусом мы получим очень хорошую передачу намерений, которая видна другим программистам.

Разумеется, у этого метода есть и недостатки. Это довольно ad-hoc решение, это бойлерплейт (вы же хотите добавить реализации Deref и DerefMut для удобства, верно?), это иной тип, что иногда может мешаться и очень длинное имя. Вдобавок, иногда нам требуется просто возможность для какой-то одной функции проигнорировать одно или два поля, но не забыть остальные с учётом тех, что могут добавить в будущем — в этом случае подход с newtype-ом может оказаться недостаточно гибким и в целом оверкиллом.

Для этих случаев годится другой способ. Мы можем воспользоваться тем фактом, что в let-биндинге может быть произвольный паттерн, который привязывает сразу несколько имён (а также тем фактом, что, начиная с версии 1.26, привязка ссылки к паттерну по значению привязывает суб-паттерны по ссылке) и явно показать, что какие-то поля мы игнорируем. Опять покажу на примере:

impl PartialEq for Big {
fn eq(&self, rhs: &Self) -> bool {
let Self { field, another, one_more, irrelevant: _ } = self;
*field == rhs.field
&& *another == rhs.another
&& *one_more == rhs.one_more
}
}

В этом случае код перестанет компилироваться, если мы добавим новые поля, так что возможность забыть их обработку исключена. Этот подход используется всюду в компиляторе самого Rust. Разумеется, это работает и с мутабельными ссылками.

#мнеприслали

(Отредактировала, но постаралась сохранить слог автора).

Наверно, начать историю следует с того, что живу я в городе с населением 250 тысяч и уже третий год работаю в такси.

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

— Пойми, что принцев не бывает. Я вот недавно поняла, что всё, что надо, я могу сама купить. Или там мастера вызвать, чтобы починить. От мужчины мне нужны всего две вещи. Он должен мочь хотя бы два раза за ночь, и у него должна быть работа. Не в Газпроме, а просто нормальная приличная работа, на которой больничные оплачивают, — монотонно рассуждает одна из пассажирок.

Они еще много что говорили, но я запомнил только эту фразу. Потому что это ведь про меня. У нас в такси как раз незадолго до этого ввели больничные, даже для ИП, коим я и являюсь. Уже успел один раз заболеть и получить деньги. Это, кстати, моя первая работа, где выплачивают больничный. По количеству раз за ночь, поверьте, я тоже подхожу.

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

Зиму сменила весна. Не та весна, которая с серым снегом и лужами во дворе, а настоящая. С маленькими зелёными листиками, травой и тёплыми вечерами. Именно в такой вечер мы приехали на загородную турбазу, справлять свадьбу племянника.

Тосты, конверты с подарками и жизнерадостный тамада — всё как положено. Но совершенно внезапно среди гостей я узнаю ту самую пассажирку. Дожидаюсь первого же медленного танца, приглашаю её, и во время невнятного топтания по дощатому полу рассказываю эту историю…

Спустя четыре месяца мы съехались.

P.S. От редакции: мне кажется, это самая романтичная история про больничные.

Свои интересные, забавные и странные истории вы можете присылать мне на почту [email protected] или в личку @ereteeva — самые-самые обязательно опубликую!