Приняты два важных RFC

Ну и в чем смысл постить это тут? Эти RFC приняли еще в прошлом месяце, кому интересно было те и так уже об этом прочитали.

Их приняли неделю назад. Технически — да, «в прошлом месяце». У меня время нашлось прочитать подробно только вчера.

кому интересно было те и так уже об этом прочитали

Чтобы прочитать, пишут авторы в блоге, а на форуме пишут, чтобы обсуждать. С учетом твоей позиции надеюсь больше тебя в этом треде не увидеть.

NLL - это полезное упрощение. Но я жду другое Rfc, там собираются убрать дублирование лайфтаймов при определении методов. Сходу ссылку не найду.

Список всех RFC.
Тот, о котором ты говоришь?

Про список знаю, не перебирать же все.

Да, про это. Количество нытья про лайфтамы упадёт в два раза.

Ты всерьез взялся за пропаганду раста на ЛОРе, я смотрю?

Оба RFC радуют, btw.
Осталось дождаться константных генериков и тогда ухх, заживет.

Количество нытья про лайфтамы упадёт в два раза.

это вряд ли

Подскажите номер RFC о том, чтобы перестать обвешивать этот язык подобными игрушками.

Если раст стремится к совместимости с Си, значит он становится человечным. Может и повод взглянуть на него.

404

Скорее к C++.

В С++ не любят вариадики в аргументах. Там вообще маразм, лишь бы не дай Селестия кто-то не обвинил что вы пишите на «Си с крестами».

В С++ не любят вариадики в аргументах.

Кто не любит?

Да встречал я таких пациентов.

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

Кстати, а зачем в нативном Rust вариативные функции? Что оно даёт по сравнению с обычным массивом (кроме трёх символов сэкономленных)?

Да хотя бы println! и иже с ним станет функцией, и Раст перестанут троллить за то, что печать производится макросом. То же касается и vec!.

I60R ★★ (06.10.2017 21:53:50) Хэйтер Rust, тегоманьяк.

Когда успели поменяться вкусы?

http://rosettacode.org/wiki/Variadic_function
Немного обидно, что Rust не представлен среди всего множества ЯП, поддерживающих вариадические функции.

Да хотя бы println! и иже с ним станет функцией

Что заставило тебя так подумать? В RFC говорится о том, что вариадики вводятся для интероперабельности с Си-кодом и должны быть unsafe.

и Раст перестанут троллить за то, что печать производится макросом. То же касается и vec!.

И println, и vec раскрываются при компиляции. Какой смысл добавлять лишний вызов функции?

Я думаю, идея в использовании функции вместо макроса больше в том, что это показывает выразительность функций. Типа, мы ж можем форматировать функциями, а вам нужны волшебные макросы.

Да хотя бы println! и иже с ним станет функцией

Что заставило тебя так подумать? В RFC говорится о том, что вариадики вводятся для интероперабельности с Си-кодом и должны быть unsafe.

Я понял вопрос I60R как «зачем нужны были бы вариадические функции в нативном Rust». В противном случае в нём нет никакого смысла, потому что то, зачем они нужны для работы с Си-кодом, описано в RFC.

и Раст перестанут троллить за то, что печать производится макросом. То же касается и vec!.

И println, и vec раскрываются при компиляции. Какой смысл добавлять лишний вызов функции?

Спасибо, мне известно, как работают макросы. Что значит «лишний вызов»? Если ты хочешь вывести на печать значение, тебе нужно это как-то сделать, ничего лишнего в этом нет. А зачем тогда все эти функции, типажи и т.д.? Всё ведь можно свести к линейному коду и goto.
Заметь, я не из этих смешных хэйтеров, придирающихся к закорючкам, меня и println!, и vec! устраивают.

Я думаю, идея в использовании функции вместо макроса больше в том, что это показывает выразительность функций

Я не вижу, чтобы эта идея продвигалась в сабжевом RFC.

Типа, мы ж можем форматировать функциями, а вам нужны волшебные макросы.

Если люди не понимают, что их функции не typesafe и больше делают в рантайме, то их мнение можно в основном игнорировать.

Я понял вопрос I60R как «зачем нужны были бы вариадические функции в нативном Rust». В противном случае в нём нет никакого смысл

То есть ты видишь смысл сделать println unsafe-функцией, а не макросом? И в чем этот смысл? Чтобы тролли не троллили?

Спасибо, мне известно, как работают макросы. Что значит «лишний вызов»?

Это значит, что ты вызываешь функцию, у которой внутри делается всё то же, что делается в развернутом println! (не совсем так, конечно, но близко).

А зачем тогда все эти функции, типажи и т.д.? Всё ведь можно свести к линейному коду и goto.

Зачем нужны трейты и функции - я понимаю. Зачем делать println! функцией, к тому же unsafe - не понимаю.

В С++ не любят вариадики в аргументах

А за что их, простите, любить? Особенно когда есть вариадические шаблоны

Хорошо, println исключаем. Типобезопасность я упустил из виду, my bad. Но ты же не отрицаешь полезность наличия вариадиков в языке?

Но ты же не отрицаешь полезность наличия вариадиков в языке?

Шаблонных - да. Сишных - нет.

Но ты же не отрицаешь полезность наличия вариадиков в языке?

Если говорить вообще - в Си++ я без них как-то обхожусь. Если о Rust - для C FFI они необходимы, но в safe Rust они не то, чтобы бесполезны, их просто не может быть, пока не придумали typesafe-реализацию.

Если говорить вообще - в Си++ я без них как-то обхожусь.

И без вариадик шаблонов и без initializer_list?

initializer_list в используемом нами компиляторе нет, а variadic-шаблоны я, естественно, использую (даже постил код sum type). Но речь шла именно именно о variadic-функциях.

Ок. я хотел «спор» в сторону увести так как от шаблонных вариадиков в расте не отказался бы.

шаблонных вариадиков

макросы не канают?

макросы не канают?

Смотря, что под этим подразумевать. macro_rules, в текущем виде мне не особо нравятся. Например, у них особые правила экспорта/импорта. Так-то приходится выкручиваться, но через функцию было бы удобнее (речь как раз о вещах типа vec!).

Процедурные макросы? Те, что с помощью proc_macro определяются.

Например, у них особые правила экспорта/импорта.

Так сложно проставить несколько macro_use/macro_export?

Процедурные макросы? Те, что с помощью proc_macro определяются.

Ну это из пушки по воробьям.

Так сложно проставить несколько macro_use/macro_export?

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

Процедурные макросы? Те, что с помощью proc_macro определяются.

Ну это из пушки по воробьям.

Мне они попроще показались. Я правда только наколенный хелловорд property на них слепил, не самый богатый опыт.

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

Процедурные макросы живут в неймспейсе крэйта, в котором определены =)

Процедурные макросы живут в неймспейсе крэйта, в котором определены =)

Ты правда не понимаешь, что я хотел сказать?

Нет, ты очень туманен в конкретике, отделываясь общими фразами. Какая именно особенность макросов на основе макроправил для тебя фатальна, не очевидно.

Начнём с того, что вопроса у меня вообще не было. Просто небольшое недовольство текущим состоянием вещей. Это ты зачем-то начал предлагать какие-то «решения».

Если нюанс про неймспейсы надо разжёвывать, то пожалуйста: например, сейчас невозможно иметь несколько разных vec! в рамках одного проекта. Не получится иметь std::vec! и my::vec!. Обычные юзинги позволяют как переименовывать сущности, так и разнести их по неймспейсам независимо от авторов библиотек.

Кстати, а зачем в нативном Rust вариативные функции? Что оно даёт по сравнению с обычным массивом (кроме трёх символов сэкономленных)?

Да хотя бы println! и иже с ним станет функцией, и Раст перестанут троллить за то, что печать производится макросом. То же касается и vec!.

Зато начнут троллить за неявные массивы при вызове вариативной функции.
И за те самые грабли, с обьявлением нескольких одинаковых функций, которые массивов не делают (в Rust они ещё ущербней будут выглядеть, ибо нет перегрузки: take_variadic, take_one, take_two, take_n... — лол, сам троллить буду)
За ещё одну «фичу» в языке, с которой придётся разбираться.
За то, что оптимизаторам придётся проверять каждую функцию, не является ли она вариативной.
За то, что это всё противоречит философии Rust.

Текущий способ явно лучше, хотя вот это будет ещё лучше. Жаль, что так медленно делают

I60R ★★ (06.10.2017 21:53:50) Хэйтер Rust, тегоманьяк.

Когда успели поменяться вкусы?

Пока они остались прежними.
И почему я хэйтер?

=============

Прошу прощения за столь поздний ответ

Жаль, что так медленно делают

Я так понимаю, что основное ядро разботчиков - человек десять, если не меньше.

Текущий способ явно лучше, хотя вот это будет ещё лучше. Жаль, что так медленно делают

Интересное решение.