でゲソ
magras
impl<'lifespan> Cell<'lifespan>
でゲソ
аааа
Vladimir
magras
Ты на что отвечал?
Да по предыдущей теме, о том, что баунды на стракте плохая практика.
Vladimir
Мне кажется не ставить баунды на структуре - это от лени
պլհկ
нет, это идиоматично
պլհկ
https://rust-lang-nursery.github.io/api-guidelines/future-proofing.html#c-struct-bounds
Денис
спасибо, я именно эту ссылку искал и не нашёл)
պլհկ
да я тоже с трудом нашел
պլհկ
помню же читал где-то
Vladimir
Падажи, тут же речь про те что выводятся дерайвом
Vladimir
Или я чёт не вкурил?
Vladimir
Я ж так понимаю оригинал поинт был: есть предположим бтримапа, нужно ли у её ключа просить орд?
պլհկ
stdlib считает, что нет
Vladimir
Ну это ж не значит что это не идиоматично, ведь так?
Vladimir
Просто гораздо проще имплы с боундами по мере необходимости
Vladimir
Нету дублирования боундов
պլհկ
не вижу профита от баундов на структах
պլհկ
все равно их заново писать в имплах
Vladimir
А вот я помню был рфц, про то, что если в структуре есть боунд, то нехер его писать в импл, и мне кажетчя после него СТД бы мог преобразиться
Vladimir
все равно их заново писать в имплах
По этому я и говорю что для ленивых, но мне кажется боунд это как статик ассерт позволяет тебе не накосячить где-то на уровень ниже
magras
պլհկ
ну значит стд лентяи писали
Sergey
Зачем нужен 'lifespan?
Sergey
Где почитать?
Vladimir
Sergey
պլհկ
Шаришь
но если в стд можно сделать скидку на то что ее писали давно, то во futures уже нельзя, а там то же самое
Vladimir
😐
Ну а чё ты, ещё бы спросил про лайфтайм 'a и 'r
Sergey
Vladimir
պլհկ
ну если все так пишут, то это и называется "идиоматично"
Vladimir
Vladimir
Но если честно, так хоть и ошибку сложнее понять, так как меньше ассертов компилятора, но код выходит чистее, особенно когда много женериков
Vladimir
Только это не значит, что он понятнее, помню был rayon там генерики решали называть более чем одной буквой, вот это было стрёмно, подозреваю, что когда у тебя генерики не будут иметь боунда вообще это тоже будет сложнее понимать
պլհկ
https://rust-lang-nursery.github.io/futures-doc/0.3.0-alpha.2/src/futures_util/stream/for_each.rs.html#13-17
պլհկ
по-моему норм тема не одной буквой называть, если начинаются на одну букву
պլհկ
например Future и Fn
պլհկ
сам тоже так делал где-то
Vladimir
magras
Я бы скорее сказал, что разница именно в требованиях.
Нужен максимально обощенный код — баунды только там где они действительно необходимы.
Нужны нормальные сообщения об ошибках в пользовательском коде — баунды в стракте.
Vladimir
например Future и Fn
Главное нейминг как у типов соблюдать, и не пересекаться с другими именами
պլհկ
Vladimir
Да, а когда их много, эт пиздец, проблема что для дженериков вроде нет конвеншина
Sergey
Мб лучше дженерики капсом?
Vladimir
Sergey
Ладно
պլհկ
Sergey
Просто есть дженериков много, хер пойми какую букву ставить, чтобы сходу понятно было.
Если PascalCase, то легко спутать с обычным типом
Sergey
Хоть префикс ставь.
TGeneric, TSome
Cat
так это по факту и есть некоторый тип
Vladimir
Мне кажется у фьюч идеально как-то вышло, еслиб ибо генерики скорее всего дублируются и хочется покороче имя, плюс чтоб опять таки не пересекались с типами, по этому до 5 букв отлично
Vladimir
Кстати в СТД либа также есть Rhs
Vladimir
Vladimir
Типа Add<Rhs>
Vladimir
Это уже к неймам генериков
Vladimir
Мы ж перешли вроде
Денис
блин, сорян, слишком быстро =)
Виктор
чего бы такого на расте написать...
Cat
Виктор
какой?
Cat
на чистом коде (бля, нме так противно это писать)
Денис
Cat
а
Денис
Anton
ну там чет стругают
Денис
https://github.com/tokio-rs/tokio-tls/pull/45/files
Anton
tokio-proto выбросили
Anton
по tower rs нормальных док нет
Anton
приходится постоянно лезть в код
Anton
tls забросили
Денис
а он работает уже?
Денис
прикольно) я хотел его посмотреть, но отстутствие доков меня остановило
надо будет глянуть всё-таки