Как поделить api на части с различным функционалом?

Question

[epitxx]

Есть структура, которая представляет из себя обертку над API.
Я хочу выделить в ней поля, через которые можно будет вызывать различные по функционалу методы.
Например:
api.account.get_balance(),
api.inventory.get()
Пытаясь реализовать это, я пришел к следующему коду:

pub struct API<'a> {
    api_key: Box<String>,
    pub part: APIPart<'a>,
}

impl API<'_> {
    fn new(api_key: &str) -> Self {
        let api_key = Box::new(api_key.to_owned());
        let part = APIPart::new(&*api_key);
        
        return Self {
            api_key,
            part,
        };
    }
}

pub struct APIPart<'a> {
    api_key: &'a str,
}

impl APIPart<'_> {
    fn new(api_key: *const String) -> Self {
        let api_key = unsafe { &*api_key };
        return Self {
            api_key,
        };
    }
    
    pub fn get_smth(&self) {
        println!("Got smth using key: {}", self.api_key);
    }
}

Так как APIPart также нужен доступ к api_key, то я сохраняю ссылку на него используя unsafe код, что теоретически должно быть безопасно при условии, что:

• Я могу изменять только внутреннее значение Box(api_key), но не сам Box
  
• APIPart не живет дольше, чем API(для этого используется лайфтайм 'a)
  

Проблема в том, что компилятор rust почему то разрешает отделить APIPart от API и использовать его даже при том, что сам API был дропнут:

pub fn foo() {
    let api = API::new("123");
    let part = api.part;
    part.get_smth();
    thread::spawn(move || {
        loop {
            part.get_smth();
            sleep(Duration::from_secs(1));
        }
    });
}

fn main() {
    foo();
    sleep(Duration::from_secs(3));
}

Я предполагал, что этот код не будет компилироваться, так как здесь получается, что APIPart живет дольше API.
Но он вполне себе компилируется и запускается с выводом:
Got smth using key: 123
Got smth using key:
Got smth using key:
Got smth using key:
что разумеется не то, чего я хочу.
RustPlayground
В общем меня интересует, почему этот код запускается, а также насколько вообще удачна такая архитектура.
Может быть есть варианты получше.

Answer 1

[Василий Банников]

Лучше это не через поля, а через методы реализовывать - тогда будет более дёшево, да и женерик лишний можно будет убрать.

Что-то типа

struct Api {
  key: String
}
struct ApiPart<'a>{
  api: &'a Api
}

impl Api {
  pub fn part<'a>(&'a self) -> ApiPart<'a> {
    ApiPart {api: self}
  }
}

PS:
Вот так делать точно не нужно:
Не надо на ровном месте городить указатели и unsafe.
У тебя из-за unsafe получился dangling pointer.

fn new(api_key: *const String) -> Self {
        let api_key = unsafe { &*api_key };
        return Self {
            api_key,
        };
    }

Норм практика делать вот так, в случае строк:

fn new(api_key: impl Into<String>) -> Self {
        let api_key = api_key.into();
        return Self {
            api_key,
        };
    }

Боксить строки также не нужно - они и так в куче лежат.

Comments

[epitxx]

В идеале я бы хотел именно через поля, ЕСЛИ такое возможно.
Если нет, ну что же буду писать скобки каждый раз.
Тем не менее твой вариант я думаю не особо мне подходит, потому что при вызове part() будет каждый раз создаваться новый APIPart.
Почему можно передавать APIPart в другой поток я вроде разобрался, я просто неправильно понимал лайфтаймы:

pub struct API<'a> {
    pub part: APIPart<'a>,
}

В данном случае lifetime(API) <= lifetime(APIPart), а я почему то считал, что наоборот.

[Василий Банников]

epitxx,

Тем не менее твой вариант я думаю не особо мне подходит, потому что при вызове part() будет каждый раз создаваться новый APIPart

Не нужно путать создание структуры в расте и создание объекта в других языках.

По факту создание ApiPart эквивалентно просто возврату ссылки на api_key - чистейший зеро кост, в чём можно убедиться, посмотрев на листинг.

В идеале я бы хотел именно через поля, ЕСЛИ такое возможно.

Не стоит это делать через поля как минимум из-за того что ты так N раз будешь копировать ссылку.

А как максимум - из-за того что это усложнит тебе написание тестов.

В идеале стоит это всё в трейты вынести.

[epitxx]

По факту создание ApiPart эквивалентно просто возврату ссылки на api_key - чистейший зеро кост, в чём можно убедиться, посмотрев на листинг.

Это может и так, если APIPart будет содержать только ссылки, но это не гарантированно.

Не стоит это делать через поля как минимум из-за того что ты так N раз будешь копировать ссылку.

О каких N раз идет речь? Имеешь в виду, если будет N разных APIPart?

[Василий Банников]

epitxx,

Это может и так, если APIPart будет содержать только ссылки, но это не гарантированно.

Только одну ссылку*.
А добавление repr transparent на структуру и inline на функцию это гарантирует.

О каких N раз идет речь? Имеешь в виду, если будет N разных APIPart?

Да.

Ещё вариант - не вводить ApiPart вообще и сделать разбиение при помощи трейтов

[epitxx]

Василий Банников,

Только одну ссылку*.

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

Пока лучшее, что я придумал это заприватить APIPart в API и сделать на него геттер.

pub struct API<'a> {
        api_key: Box<String>,
        part: APIPart<'a>,
    }
    
    impl API<'_> {
        pub fn new(api_key: &str) -> Self {
            let api_key = Box::new(api_key.to_owned());
            let part = APIPart::new(&*api_key);
            
            return Self {
                api_key,
                part,
            };
        }
        
        pub fn part(&self) -> &APIPart {
            return &self.part;
        }
    }

Хотя это не идеально, если в APIPart будут данные которые нужно будет мутировать, то понадобится еще метод типа part_mut().

Ещё вариант - не вводить ApiPart вообще и сделать разбиение при помощи трейтов

Не совсем понимаю, что конкретно имеется в виду.
Если просто

trait APIPart {
    //...
}

impl APIPart for API {
    //...
}

то это не вариант.
Весь смысл APIPart как раз в том, чтобы сгруппировать одинаковую по смыслу логику.
А так все методы будут напрямую в API.

[Василий Банников]

epitxx,

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

Например?

Хотя это не идеально, если в APIPart будут данные которые нужно будет мутировать, то понадобится еще метод типа part_mut().

Например?