Сделать X публичным. Как это не странно. Ну по крайней мере как я понял с твоего абстрактного описания (лучше б 10 строчек кода на плейграунде б сделал).
Он используется в публичном интерфейсе, значит должен быть публичным. То что ты в явном виде сейчас не видишь Х, не означает, что Х не нужен компилятору.
И метод foo.bar() из A<X> ,будет развернут в что-то типа <Foo as A<X>>::bar(& foo).

А чем тебе мультитредовский рантайм не подходит и обычные spawn?
Если у тебя в требованиях только один "воркер". То ты можешь создать одну тачку которая бы обрабатывала все приходящее из канала.

async fn main(){
let (tx, rx) = channel(); 
let t = tokio::spawn(channel_handler(rx));
...
actix_web().await;
t.await;
}
async fn channel_handler(rx: Receiver<Foo>)
loop {
rx.next().await.unwrap().foo_method().await;
}

Примерно такой псевдокод может быть.

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

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

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

Даже если его нет на уровне объектов у пользователя, ты зачем-то его используешь на уровне типов. А значит всё-таки он нужен. Например в случае конфликтов имён методов, пользователю явно нужно будет указать откуда этот метод. Тогда он этот Х точно затребует.

sprs если будут нужны матричные операции и данные достаточно разряжены(больше 50% дырок). Использовал в лабораторных - без нареканий

Спасибо, гляну

Там точно есть csr. Дешевые арифм операции и получение срезов по строкам(по столбцам подороже)

Вообще, я этот "паттерн"(с трейтами A и B, который я описал) использовал для того, чтобы обобщить повторяющуюся часть имплементации нескольких частично схожих объектов в своем крейте. При этом B мне фактически нужен только для того, чтобы получать приватную информацию об объекте(собственно это и есть тот самый X), а A делает фактическую имплементацию через дефолтную имплементацию собственных трейтных методов.

Может быть это можно было сделать как-то проще?

Плейграунд сделал )

https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=1c76775ab01bb8395120037b7411a962

1. Ну скорее всего у тебя тут Х не тайп параметр, а ассоциативный тип должен быть.
2. trait A: B, боунд наверное тоже не обязателен, так как B у тебя просто "детали реализации".
3. Ну и вообще трейт B, имхо, это попытка натянуть ООП, на Раст, по хорошему Трейт должен описывать поведение, а не реализовывать доступ к полям.



Как это можно написать учитывая 1-2:

trait B {
type X;
fn inner(&mut self) -> &mut Self::A
}
impl B for S<T>{type X = T;...}
...
trait A{
fn reset(&mut self);
}

impl<X> A for X
where X: B,
<X as B>::X : Default,
{
fn reset(&mut self) ->{* self.inner = Default::default()}
}

@c_vld Идею понял. Спасибо!

Надеюсь, когда-нибудь настанет и у нас этот день, когда весь компилятор будет написан на Rust, а бутстрапиться через mrustc - Zig стал работать над этой задачей - отсоединение от LLVM https://kristoff.it/blog/zig-new-relationship-llvm/

Ну бутстрап происходит уже сейчас.
Для отказа от LLVM нужно просто допилить интеграцию с cranelift

#вопрос Коллеги, кто знаком с juniper, два вопроса:
Вопрос первый.

#[derive(juniper::GraphQLObject)]
struct Test<T> { t: T }

не работает. Какие есть пути для того, чтобы такие объекты можно было толкать в Query/Mutations? Нужно потребовать juniper::ScalarValue для T? А если это необязательно скаляр?

Вопрос второй:

#[derive(juniper::GraphQLObject)]
struct Test { 
   t: HashMap<String, serde_json::Value>
}

так тоже не работает, для структуры не может вывестись вот тот трейт. Что нужно сделать? (в примерах juniper что-то не нашёл)

По-видимому, тебе снова вопрос, @tyranron😉

Но вообще подозреваю, что это будет адски тормозить.

Кодогенерация через crane lift? Или bootstrap?

Да, сборка через cranelift.
Из-за того, что компилятор раста всегда бутстрапится (потому что написан на расте), если stage1 была собрана без оптимизаций (или слабым оптимизатором), то в итоге она потратит куда больше времени на сборку stage2.

Не, я бутстрап имел ввиду в терминах портирования на новыю платформу, через Си компилер и mrustc

Обычно, если компилятор языка X написан на X, то он всегда бутстрапится