Иди топи чтобы в синтаксис println! запилили, а то макросами нехорошо

лол, там внутри ланг итем энивэй

где твой бог теперь

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

Вот тут плюс потому что это функция нарушающая правила борровинга и для которой есть отдельный костыль в borrowck А сделали бы синтаксисом — был бы явный дроп с мувом из контекста

Вот тут плюс потому что это функция нарушающая правила борровинга и для которой есть отдельный костыль в borrowck А сделали бы синтаксисом — был бы явный дроп с мувом из контекста

нука поподробнее

че за костыли

Я тоже не понял х)

нука поподробнее

Так ща

https://doc.rust-lang.org/src/std/macros.rs.html#371-374

Я чет уже не уверен

Мув семантика наверное

Костыль

пиздатый макрос да?

drop мувает как функция?

drop мувает как функция?

Да

Тогда всё ок, я спутал с сигнатурой Drop:💧

Дроп это пустая функция

Лелега блять)

fn drop<T>(val: T) {}

fn drop<T>(val: T) {}

Уже вижу, сорри

пиздатый макрос да?

Просто потому что тогда еще макросов процедурных не было

Если для трай нельзя сделать fn try<FnMut()->Y>(f:F)->Y{f()} то почему для троп сделали, хочу равноправия

> I think it's massively overhyped. I don't have an inherent objection to the idea of a safer systems programming language, but one developed primarily by academics with no real job experience and apparently designed to appeal to webdevs who don't have much low-level experience anyway isn't exactly one that I want to succeed. The Rust Evangelism Strike Force annoys me as well.

Если для трай нельзя сделать fn try<FnMut()->Y>(f:F)->Y{f()} то почему для троп сделали, хочу равноправия

Потому что некрасиво

let pook = try(|| { let a = do_one(x)?; let b = do_two(a)?; Ok(b) });

Ну окей

Для Кетч анвинда тоже ж завезут синтаксис?

Надеюсь, нет

А то на паниках начнут логику писать

Как в джаве на эксепшнах

помню как 2 года назад все орали ВОПРОСИК НЕ НУЖЕН ЗАЧЕМ НАМ СИНТАКСИС МОЖЕМ И TRY! НАПИСАТЬ

сейчас уже try! не найдешь в коде

с try блоком будет то же самое, инфа сотка

да понятно что ланг итем лучше макроса

вопрос в том, стоит ли так писать

или говный синтаксис - благо, которое радует глаз?

или говный синтаксис - благо, которое радует глаз?

Конечно do нотация решит все проблемы, но лангуаге десигнеры не смогли в do, поэтому для except-монады try, для list-монады for, для future-монады - async. Для всего свой синтаксис.

Там ещё трансформеры как-то надо им будет уложить.

(Когда except в async в IO)

не факт что этосложнее

они там вроде говорили, почему ду не очень

они там вроде говорили, почему ду не очень

да, лодочник писал, что у них в итераторах конкретные типы, потому что зирокост. И это конфликтует с do-нотацией. Если бы они смогли обобщить итераторы, но сохранить зирокост, тогда бы у них получилось.

try в асинке так же работает как и везде

не понял в чем проблема

помню как 2 года назад все орали ВОПРОСИК НЕ НУЖЕН ЗАЧЕМ НАМ СИНТАКСИС МОЖЕМ И TRY! НАПИСАТЬ

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

При этом можно быть несогласным с заменой try!

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

А теперь — try!, await! и т.д., всё в мусоор

await остался так-то

Конечно do нотация решит все проблемы, но лангуаге десигнеры не смогли в do, поэтому для except-монады try, для list-монады for, для future-монады - async. Для всего свой синтаксис.

++

await остался так-то

Пока

Жиза, раньше не плодили синтаксис, так как считали что лучше один обобщенный способ который позволяет делать нужную фичу, а потом его можно макросом обернуть

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

не вижу тут повода для гордости, если цель не лиспоебство

нет бы for со скалы скопипастить

А сейчас на каждый кейс который часто юзают завозят синтаксис

нет бы for со скалы скопипастить

А что там?

ну такая do-нотация, которая не пугает джавистов, потому что выглядит как for))

работа с ошибками как была хуевая, так и осталась

работа с ошибками как была хуевая, так и осталась

А где классная?

не вижу тут повода для гордости, если цель не лиспоебство

Ну, возможность сменить имплементацию #[async] это довольно таки мощно. Скажем, хочешь ты, чтобы join(a, b) можно было херичить прямо в await!, допиливаешь форму let (a, b) = await!(a, b), хотя она первоначально не предполагалась

А если у тебя await — keyword, то ты сосёшь

ну такая do-нотация, которая не пугает джавистов, потому что выглядит как for))

С Паскаля спиздили

И вынужден делать await join(a, b)

for a<1 to 5

напиши свой макрос

ну разница-то в том, что to — метод, а не ключевое слово

await2!

поэтому такой цикл — это на самом деле map рэнджа

ну или foreach, в зависимости от тела

Ну и получаешь неконсистентность с обычным await, который кейворд. Зачем, спрашивается?

1) но кейворда await нет 2) пусть нам @Psilon расскажет как плох авэйт там где он есть

1) Пока нет. Он будет, просто не договорились о приоритете оператора

2) авейт ваще заебись, жду не дождусь его в стейбле

1) но кейворда await нет 2) пусть нам @Psilon расскажет как плох авэйт там где он есть

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

2) авейт ваще заебись, жду не дождусь его в стейбле

но ведь await a,b нельзя написать

нахуй такой await нужен спрашивается

и даже await a | b нельзя

это что вообще такое

придумал идею для стартапа

за имплементить + и | для фьюч

+ = join | = select