Ну, например, как в сессионных типах

https://github.com/Munksgaard/session-types/blob/master/src/lib.rs#L145

Ну или вот. Send дуален Recv

reciprocal всё же правильнее

Обоюдный

https://github.com/Munksgaard/session-types/blob/master/src/lib.rs#L145

Сложно. Надо разбираться

Ну, то есть https://doc.rust-lang.org/std/convert/trait.Into.html#implementors

Дока забавная

Дока забавная

> There is one exception to implementing Into, and it's kind of esoteric.

xd

Сложно. Надо разбираться

Конечно, надо. Возможность делать сессионку это то отличие, которым можно тыкать в лицо хаскелистам

Ибо линейные типы (#[must_use]) и аффинные (move-семантика)

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

интересный топик. а к примеру есть тип круг и есть тип овал. и необходимо сделать конвертирование из одного в другое. разве в этом случае From/Into не самое оно ?

Из круга в овал кажется норм

Ну, я уверен, что есть кейсы, когда from/into внутри нужно юзать. Но конкретно тут я бы смотрел на ситуацию шире: для чего это надо?

я понял для чего From/Into, чтобы эмулировать наследование и иерархию классов

Ну, круги и овалы, это либо рисование (конвертация не нужны), либо физический движок (тут вроде тоже)

я понял для чего From/Into, чтобы эмулировать наследование и иерархию классов

толсто

держу марку

маладца

Ну, я уверен, что есть кейсы, когда from/into внутри нужно юзать. Но конкретно тут я бы смотрел на ситуацию шире: для чего это надо?

сейчас реальный кейс не приведу. овалы / круги это как вариант был. но когда стал раст изучать и столкнулся с From / Into, то воспринял это как вариант для обозначения конвертирования одного типа в другой. К примеру есть какой-то DTO объект и его нужно в другое представление превратить. Можно свой какой-то метод запилить в стиле circle_to_ellipse но это будет частное, а тут есть из std трейт и реализовав его получаешь общее для всего раст описание перехода из типа в тип без навязывания реализации

Ну, правильно, для конвертации

Мой поинт в том, что внутри либы конвертацию всегда избегать надо

это, кмк. логично

Мой поинт в том, что внутри либы конвертацию всегда избегать надо

ну к примеру. кейс №1: я пишу либу, которая должна рисовать графики. с одной стороны я хочу дать пользователю либы возможность оперировать на разных уровнях (от низкого - рисовать точки, линии, до высокого - в стиле, я хочу гистограмму, вот тебе данные вот такие, а вот тут поверх нарисуй среднюю по таким-то параметрам). отсюда выходит что у либы будет несколько слоев логики, где в финале все должно превратиться в точки. На более высоких уровнях будут структуры описывающие детали гистограм, из размерности и т.п. но они в итоге должны быть преобразованы в более низкий уровень такой как вот такие точки такого цвета, а вот тут такого (при условии что мы в растр рисуем). чем будет плохо тут преобразование структур юзая From/Into более высокого уровня в серию структур более низкого уровня такие как серия точек? кейс №2 вот есть сторонняя либа, и автор этой либы не особо спроектировал (или наоборот так сделал специально) интерфейс и я не могу сделать println!("{:?}",x) потому что у него нет #[derive(Debug)] в его крейте. И это в общем-то порой доставляет неудобств с практической точки зрения. Я это к тому что как пользователь либы, я бы ожидал что либа будет давать варианты сделать конвертацию в стандартные типы (если это применимо к тому что решает либа) или в какие-то структуры которые задуманы как публичный интерфейс либы для ее использования

Кейс 2 это не "внутри либы", это как раз про взаимодействие с другими крейтами (std тоже "внешний"), об этом я писал, что это норм кейс для from/to

Если говорить про первый кейс, то, во-первых, каждый слой должен быть в отдельном крейте, имхо

Кейс 2 это не "внутри либы", это как раз про взаимодействие с другими крейтами (std тоже "внешний"), об этом я писал, что это норм кейс для from/to

ага, ок. тогда ок

И тут правила конвертации как между крейтами

Но даже в этом случае я сомневаюсь, что from лучше использовать, его тупо не хватит

Дело в том, что чтобы сложную фигуру в примитивы перегнать, тебе как минимум параметр качества нужен

Ну, скажем, сферу триангулировать хочешь

Или огружность прямыми рисуешь

Так что либо параметр качества, либо нижний уровень сам определяет (смотрит на размеры фигуры и полотна), но и в этом случае контекста не хватает

твой кейс понял. в этом плане да, тут контекст играет немаловажную роль 🙂

Я уже молчу о том, что маловероятно, что ты хочешь From<Circle>, скорее всего будет From<&Circle>

Что чуть противоречит логике, сам понимаешь )

ну да 🙂 это да

данке за фидбек 🙂

“Why Rust is the future of robotics” https://medium.com/pollenrobotics/why-rust-is-the-future-of-robotics-81d7fb68fe37

rustobotics

Кейс 2 это не "внутри либы", это как раз про взаимодействие с другими крейтами (std тоже "внешний"), об этом я писал, что это норм кейс для from/to

кстати а можно ли будет как-то реализовать Debug для внешнего типа?

Нет

Что правильно, кмк. Нехрен в кишки лезть

а как тогда правильно решить тот кейс?

хочу println! для внешнего типа

а как тогда правильно решить тот кейс?

Какой кейс у тебя

хочу println! для внешнего типа

Заворачивай его в свою обёртку

а видимо придется сделать трейт

хотелось иметь пачку элементов и делать им format

Не понятно

напишу позже кейс

Заворачивай его в свою обёртку

так не получится. твоя обертка будет иметь дебаг, но то что она оборачивает - нет. потому прийдется писать мануальненько свой дебаг и принтить то что нужно

уупс, сорян)

а если вот так: https://play.rust-lang.org/?gist=2f26da0bc06f7cc585c0a556cbadfb99&version=stable ?

или я переусложнил и можно проще?

в смысле чтобы не везде таскать обёртку для типа без std::fmt::Debug, а использовать её только для печати

У кого-нибудль была такая херня? cargo check просто повисает при сборке, загрузка проца низкая, памяти тоже еще навалом.

У кого-нибудль была такая херня? cargo check просто повисает при сборке, загрузка проца низкая, памяти тоже еще навалом.

файл какойнить залочился

другим процессом каким нить

у меня было такое

когда в разных окнах терминала cargo build запустил

файл какойнить залочился

Слуш, ну после сноса target/ то же самое

Именно на сборке лочится

Не на ожидании локфайла

ну дык он и Cargo.lock

лочит

> не на ожидании локфайла

а. сорян. пропустил

Другие процессы не запущены

После cargo clean

То же самое

в проессах нет?

в проессах нет?

Висит rustup и rustc

кильни

@mersinvald у тебя не воркспейс

случаем?

Нет

кильни

Киньнул)

Перезапустил

То же самое