Как мне указать, что любой тип, удовлетворяющий заданной первой черте под определенными границами черты, должен также неявно удовлетворять второй черте? - PullRequest
Новая
       48

Как мне указать, что любой тип, удовлетворяющий заданной первой черте под определенными границами черты, должен также неявно удовлетворять второй черте?

0 голосов
/ 14 апреля 2019

У меня похожая ситуация, как Невозможно tokio :: запустить штучную упаковку Future, потому что отправка, связанная с чертой, не удовлетворена ): я хочу использовать tokio::run для типов Box<T: Future ...>, где T не реализует Send.

Моя ситуация отличается тем, что я не написал метод, который возвращает мой Box, и поэтому не могу изменить сигнатуру его метода. Он выполняет веб-запрос и возвращает это будущее в штучной упаковке: 

pub fn get_resource(&self,) -> Box<Future<Item = RestStruct, Error = Error<serde_json::Value>>>

Обратите внимание на отсутствие Send.

Согласно документации Tokio , мне нужно реализовать Send для моего коробочного типа, который не является автоматическим, даже если будущие связанные типы Send:

Проницательные читатели могут заметить явную нотацию Send в определении Box. Запись добавлена, потому что Future не является явно Send по умолчанию; это вызывает проблемы позже при попытке передать это будущее или одно из его производных в tokio::run.

У меня проблемы с поиском подходящего лаконичного способа сделать это. Кажется, что-то вроде этого должно работать: 

impl<T, I, E> Send for T
where
    T: Future<Item = I, Error = E>,
    I: Send,
    E: Send,
{
}

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

Ошибки, которые вызвала мое решение:

черта std::marker::Send требует unsafe impl декларации

Мне кажется, я понимаю, что это основано на документации о Send, хотя и для пояснения: это действительно будет "правильно реализовано Send", как описано здесь , потому что связанные типы Send

параметр типа T должен использоваться в качестве параметра типа для некоторого локального типа (например, MyStruct<T>)

Я понимаю, что это связано с обходным решением newtype, как описано в документах , которое действительно мешало бы делать то, что я хочу делать, если это так. Значит ли это, что я не могу добиться того, чего хочу? Есть ли что-то вроде псевдонима типа для ограниченных черт, которые могли бы обойти это?

конфликтующие реализации черты std::marker::Send для типа &_

Этого я совсем не понимаю. &_ гораздо шире, чем тип с ограничениями, который я пытался указать, используя все эти where границы; Я бы не ожидал, что &_ будет Future<Item = I: Send, Error = E: Send>.

...