#prog #abnormalprogramming

Это мы любим

В праздничные выходные мне пришло в голову, что я давно не занимался чем-то бессмысленным. Представляю вашем вниманию... Regex Chess: набор из 84688 регулярных выражений, которые при выполнении по порядку генерируют ход (валидный, то есть не совсем ужасный) для переданного в качестве входных данных состояния шахматной доски.

Шахматный движок на 84688 регулярных выражениях
https://habr.com/ru/articles/872186/

Я записал демку на два хода, оцените как оно работает "под капотом"

Оригинал
A 2-ply minimax chess engine in 84,688 regular expressions
https://nicholas.carlini.com/writing/2025/regex-chess.html
+
GitHub (даже тесты есть 🌝)
https://github.com/carlini/regex-chess
+
Demo
https://nicholas.carlini.com/writing/2025/regex-chess.html

Почему авторы ООП-языков предпочитают пилить костыли для частных plain data классов (dataclass/NamedTuple в Python, data class в Kotlin, record в Java и C#, case class в Scala, Data в Ruby) вместо того, чтобы сделать общий механизм для реализации протоколов/интерфейсов вроде deriving в Haskell?

The goal isn't to write more code faster. It's to build better software.

(с) https://addyo.substack.com/p/the-70-problem-hard-truths-about

#prog #rust #article

Why nextest is process-per-test

Я хочу сто долларов, сто раз.

#prog #cpp #meme

А напротив — match

#prog #rust (и несколько #anime) #meme

Source

#prog #rust #meme

Femboy affiliations

Source

#prog #haskell #meme

Source

#prog #rust #rustreleasenotes

Вышла версия Rust 1.84.0! Как всегда, тут только некоторые вещи, а остальное в полных заметках о релизе.

▪️Когерентность — свойство системы типов Rust: для любой наперёд заданной пары трейта и типа существует не более одного impl-а этого трейта для этого типа. Очень важное свойство, которое позволяет генерировать код и не беспокоится, что один и тот же метод будет означать разные вещи в разных местах кодовой базы. Новый порешатель трейтов trait solver (нет, не chalk, хотя и вдохновлён им) теперь используется для проверки когерентности. С точки зрения программиста это означает, что компилятор теперь корректно находит больше перекрывающихся impl-ов и корректно различает больше impl-ов, которые точно не перекрываются. Если вы пытались соорудить какую-то type-level фигню, которая не работала из-за conflicting implementations..., хотя вроде как должна — попробуйте сейчас. И да, это означает, что ваш код, вероятно, компилировался по недосмотру из-за бага компилятора, как derive-visitor (не волнуйтесь, там код уже поправили).

▪️#[deny(lint_name)] внутри #[forbid(lint_name)] теперь работает и продолжает запрещать lint_name, и нет, это не позволяет переопределить forbid. Само по себе не очень полезно, но это изменение хорошо для макросов, которые генерирую код с #[deny] в контексте, где действует #[forbid]. Предупреждения на это не выдаётся (к моему неудовольствию).

▪️У трейт-объектов, составленных из Trait + AutoTrait, при приведении теперь можно отбрасывать части, которые не соответствуют авто-трейтам. Например, теперь компилируется этот код:

trait Trait {}

fn upcast(x: &(dyn Trait + Send)) -> &dyn Send { x }

▪️Я уже ссылался на статью про различие place expression. Так как непосредственно разыменовывание указателя не является UB — UB может являться последующая конвертация из place expression в value expression — взятие &raw {, const} (или, аналогично, addr_of{, _mut}!) от результата разыменовывания сырого указателя всегда является безопасной операцией. Да, даже если указатель null. Взятие адреса от доступа к полю place expression остаётся в общем случае unsafe, поскольку это требует, чтобы указатель был в пределах выделенной под значения указываемого типа памяти.

▪️Косвенно связанное изменение — добавили линт на образование сырого указателя, который немедленно становится висячим из-за того, что указывает на дропнутое временное значение. Это расширило предыдущий аналогичный линт, который предупреждал о сыром указателе из временной CString. В коде отмечается, что у линта пока есть false negative, так что целиком полагаться на это пока не стоит. С другой стороны, там же указаны конкретные операции, которые пока не проверяются, так что стоит ожидать увеличения полноты этого линта в будущем.

▪️Как я уже ссылался, касты между указателями и числами имеют на удивлению неоднозначную семантику — главным образом потому, что для корректной оптимизации кода с указателями надо знать их происхождение (provenance), а эта информация при касте из указателя в число теряется, и её потом неоткуда взять при обратном касте из числа в указатель. В стандартную библиотеку добавили API для манипуляции с адресами указателей, которые более явны насчёт того, что при этом происходит с provenance. Подробнее в документации на указатели.

▪️На примитивных численных типах стабилизировали метод isqrt, возвращающий округлённый вниз квадратный корень. Для знаковых чисел этот метод паникует на негативных значениях. Для обработки этой ситуации можно использовать checked_isqrt, который возвращает None для негативных значений. У NonZero этот метод тоже есть, но почему-то только для беззнаковых оборачиваемых типов.

▪️cargo теперь может выбирать версии зависимостей, принимая во внимание их MSRV (minimum supported Rust version). Это opt-in, но будет использоваться по умолчанию в третьей версии резолвера зависимостей, которая будет использоваться по умолчанию в edition 2024 (стабилизация в следующей версии!)

LinkedIn - это Tinder наоборот.

Девушки пишут задротам, а те им не отвечают

😂

Какая ещё, к чёрту, лента в приложении для заказа такси?

#meme, который вам нравится?..