Size: a a a

2020 August 03

V

Vetro in Rust Async
потому что компилятору нужны гарантии
источник

DZ

Dmitriy Zhiλtsov in Rust Async
ну те есть типы которые позволяют шарить себя через треды есть типы которые не могут этого делать и их приходится сериализовать
источник

DZ

Dmitriy Zhiλtsov in Rust Async
ясн
источник

DZ

Dmitriy Zhiλtsov in Rust Async
те если я например добавлю в структуру поле с Https сокетом навешу Send - мне компилятор пошлет?
источник

V

Vetro in Rust Async
смотри

если бы допустим, ты сделал так

impl<T> Message for Rc<T>
where T: Message
{}
источник

V

Vetro in Rust Async
то из-за того что у тебя висит Send в Box<dyn Message + Send>
источник

V

Vetro in Rust Async
он не даст тебе пихнуть туда Rc<Foo>
источник

V

Vetro in Rust Async
именно поэтому явно и выставляется
источник

DZ

Dmitriy Zhiλtsov in Rust Async
Vetro
он не даст тебе пихнуть туда Rc<Foo>
ясно теперь понял
источник

AV

A V in Rust Async
источник

JC

John Cantrell in Rust Async
У async-std совместимость между минорными релизами не гарантируется?
источник

BV

Boris Vinogradov in Rust Async
John Cantrell
У async-std совместимость между минорными релизами не гарантируется?
исправил* У async-std совместимость не гаранитруется
источник

AV

A V in Rust Async
а) половина async-std - feature = ["unstable"]
б) https://t.me/rust_async/25500
источник

AV

A V in Rust Async
источник

D

Denis in Rust Async
... опять ...
источник

D

Denis in Rust Async
впрочем, ничего нового
источник
2020 August 04

V

Vetro in Rust Async
Всем добрый день и хорошего дня!

Имеется вопрос по правильности реализации враппера вокруг структур, имеющих асинхронный метод.
Сначала пара слов про то, что это и зачем оно нужно. Сейчас для каждой структуры в библиотеке реализуется специальный трейт Request, отвечающий как раз за исполнение запроса, связанного с этой структурой. В итоге клиенту нужно писать что-то вроде:

SendMessage::new().disable_notification(true).send().await;


Для того, чтобы избавиться от явного прописывания send() для каждого запроса, так как семантически вернее представлять его как раз как футуру, было принято решение написать враппер вокруг любого impl Request, для того, чтобы можно было во внутренностях возвращать пользователю этот враппер и позволить писать что-то вроде такого:

let mut send_message = bot.send_message();
send_message.disable_notification(true);
send_message.await;


Соответственно вопрос, насколько будет верна такая реализация?

Ссылка:
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=9a9bff393b6f7d03ca946bf9efe20663

заранее спасибо.
источник

V

Vetro in Rust Async
вопрос идет именно о подноготной реализации Future для Wrapper
источник

A

Adv0cat in Rust Async
Vetro
Всем добрый день и хорошего дня!

Имеется вопрос по правильности реализации враппера вокруг структур, имеющих асинхронный метод.
Сначала пара слов про то, что это и зачем оно нужно. Сейчас для каждой структуры в библиотеке реализуется специальный трейт Request, отвечающий как раз за исполнение запроса, связанного с этой структурой. В итоге клиенту нужно писать что-то вроде:

SendMessage::new().disable_notification(true).send().await;


Для того, чтобы избавиться от явного прописывания send() для каждого запроса, так как семантически вернее представлять его как раз как футуру, было принято решение написать враппер вокруг любого impl Request, для того, чтобы можно было во внутренностях возвращать пользователю этот враппер и позволить писать что-то вроде такого:

let mut send_message = bot.send_message();
send_message.disable_notification(true);
send_message.await;


Соответственно вопрос, насколько будет верна такая реализация?

Ссылка:
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=9a9bff393b6f7d03ca946bf9efe20663

заранее спасибо.
Может тогда сделать что-то типо:
let mut request = RequestBuilder::new()
request.disable_notification = true;
bot.send_message(request).await;
источник

V

Vetro in Rust Async
impl Request уже представляет из себя билдер
источник