Rust 1.34

польза инклюдов в расте в том, что их там нет в каждом первом файле

Нет. Так ты на talks не нафармишь.

А вот с динамикой начинается веселье: в ржавчике нужна ровно одна строчка, что бы сделать тип (де)сериализируемым

А как в расте с рефлексией/интроспекцией без макросов? В D, например, вообще ничего не нужно добавлять, чтобы сделать тип (де)сериализуемым. Там библиотека сама разбирает тип в компайл-тайме и генерирует нужный код.

Там библиотека сама разбирает тип в компайл-тайме и генерирует нужный код.

В расте так же.

В расте так же.

Т.е. без макросов?

С помощью процедурных макросов.

С помощью процедурных макросов.

Так я же спросил есть ли рефлексия без макросов. Так что в расте совсем не так как в D.

Да и хрен с ними, с лолксами, когда и тут весело :D

Её и с макросами нет.

Так я же спросил есть ли рефлексия без макросов

Рефлексия, которая подразумевает самомодификацию программы во время выполнения? Кажись такой херни в русте нет и слава Богу!

Не. Рефлексия - это когда можно получить список полей структуры, например.

Рефлексия - это когда можно получить список полей структуры

нет. а в компайл-тайм чем не устраивает, конкретно?

Рефлексия, которая подразумевает самомодификацию программы во время выполнения? Кажись такой херни в русте нет и слава Богу!

Рефлексия это как сказано выше, возможность в компайл-тайме узнать характеристики обрабатываемых типов. Это точно не хрень, потому что AST макросы раста предоставляют ровно ту же возможность. Это просто разные механизмы. Более того, AST макросы это более мощный инструмент, чем просто рефлексия, так как позволяют именно реализовать тот ужас, что вы описали. Именно по этой причине, что AST макросы слишком мощный инструмент, который позволяет легко стрелять в ногу, их нет в D. Это принципиальная позиция Уолтера Брайта, автора D, хотя его не однократно просили об этом. Просто рефлексия, средствами языка без макросов AST, реализована в D. В принципе, результат тот же самый, но в D рефлексия реализована средствами языка без макросов, т.е. нет необходимости учить какой-то еще один внутренний язык. Что в итоге практичнее - покажет время.

нет необходимости учить какой-то еще один внутренний язык

Процедурные макросы в расте пишутся на расте.

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

Для процедурных - нет.

AST макросы раста

Нигде не используются

Процедурные макросы раста работают над потоком токенов, а не с AST компилятора, в этом и проблема, они например не имеют доступа к внешнему контексту. В кастом дерайве ты видишь что у структуры есть поле data: Buffer, но никакие семантические запросы про этот Buffer сделать невозможно, это просто текст.

AST-плагины тоже есть, но все кто мог уже перекатились на токенстримовые, так как внутренний AST раста нестабилен.

Лол, ты совсем поехавший?

Я б те вдул, мой голый, дряблый кирк.

Решил полистать растбук чтобы приобщиться к прекрасному, сразу же наткнулся на подобное, хотелось бы пояснений...

(1) <i8>::max_value() получили максимальное значение для типа <f32>::max_value() получили ошибку

(2) std::i8::MAX получили максимальное значение std::f32::MAX получили максимальное значение

Вопрос к ситуации (1) это такой архитектурный промах у удобопредсказуемости языка или в этом есть какой-то сакральный смысл?

есть еще std::f32::INFINITY, отличное от MAX

Для начала с русским разберитесь.

есть, но вопрос был не в этом, а именно в том, что странно как-то выглядит эта несогласованность интерфейсов, в варианте (2) мы имеем предсказуемое поведение в этом плане, в варианте (1) - нет. Вот и стало интересно по какой причине так. Были ли какие-то объективные причины делать так?

Очень, конечно, по существу.

Не вижу проблемы ни в первом ни во втором случае, ну кроме огрехов самого кода, значит ли это что мне осталось жить не так уж долго с такими тяжелыми болезнями?

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

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

ХЗ. Наверно потому что для целочисленных типов - только одно максимальное значение. А у плавающей точки два - плюс бесконечность (правильно, но не очень полезно) и максимальное представимое число.

Были ли какие-то объективные причины делать так?

не знаю. если и были, сейчас трудно найти соответствующие обсуждения. тем более оба варианта стабилизированы в 1.0 - значит, впилены были еще в 0.*

не то чтобы для меня отсутствие <f32>::max_value() выглядит странно, но лучше бы std::f32::MAX был назван MAX_FINITE