57:00 Коду компилятора, который кастит толстый указатель к тонкому, можно вообще не думать про layout FatPtr в памяти, потому что указатель на структуру == указатель на первое поле.
1:15:10 - Проще говоря, проблема в том что мы пытаемся записать в &mut self ссылку, полученную из того же &mut self. Т.е. пытаемся сделать self referential тип.
Про subtyping ужасно сумбурно пояснил. Хоть и в rustonomicon это тоже подано сложно, но все равно понял. Хороший пример такой можно привести из наследования C++. Наследуемый/родительский тип всегда меньше чем дочерний, поскольку дочерний содержит и данные родителя и свои уникальные. По этой логике Красноярский край является подтипом города Красноярска. С lifetype subtyping та же логика. В растономиконе, тоже пример был географический.
В примере с реализацией IterMut из слайса с сырыми указателями begin и end в состоянии не очень понятно, откуда берется гарантия, что их потом можно разыменовывать. Хоть они и не объявлены как pub, их все равно хотя бы в текущем модуле можно изменить на произвольные значения, для чего unsafe не потребуется. А вот метод, который их будет в unsafe разыменовывать, получается что должен полагаться на корректность кода в safe (или даже на отсутствие такого кода), что как бы противоречит первоначальной идее. В более общем случае с сырыми указателями возникают новые инварианты, которые unsafe код не может проверить, а safe код может нарушить. Что-то ключевое в понимании этой философии у меня ускользает.
Идея в том, что unsafe распространяется на весь модуль. Так что да, unsafe полагается на соседний safe код и наоборот. Поэтому нужно стараться изолировать unsafe код в как можно более простом и маленьком модуле. Подробно про это рассказывается на следующей лекции
Не уверн, что соглашусь -- для хаскелевского IO нет аналога safe abstraction. Нельзя оберунть заражённый IO интерфейс в sans-IO. А главная мысль растового usnafe как раз в том, что сверху unsafe можно сделать не-usnafe абстракцию. Тут аналогия скорее с unsafePerformIO.
Если предварительно что-нибудь посмотреть на эту тему - то понять можно, хотя бы частично. Вот тут разжевано про вариантность в Java: th-cam.com/video/tlAGSScIu_w/w-d-xo.html
Сразу понятно почему не стал объяснять контравариантность ф-ии по аргументу и результату. Ну это же очевидно. А почему не объяснил? Потому что вообще не раскрыл термин variance который можно просто стащить с rustonomicon-а
![เจ็บที่ยังฮัก - ม่อน วรวิทย์ [ Official Mv ] จอนนี่มิวสิค](http://i.ytimg.com/vi/KALIGSRSjFs/mqdefault.jpg)
![ร้อยพ่อพันแม่ - WanMai [Official MV]](http://i.ytimg.com/vi/XY2pNYASEbg/mqdefault.jpg)
Нифига не понятно, но ооооочень интересно 🧐
57:00 Коду компилятора, который кастит толстый указатель к тонкому, можно вообще не думать про layout FatPtr в памяти, потому что указатель на структуру == указатель на первое поле.
1:36:52 После фокуса на то, что даже уникальные ссылки ковартианты по собственному лайфтайму, всё равно сказал, что наличие PhantomData
1:15:10 - Проще говоря, проблема в том что мы пытаемся записать в &mut self ссылку, полученную из того же &mut self. Т.е. пытаемся сделать self referential тип.
Про subtyping ужасно сумбурно пояснил. Хоть и в rustonomicon это тоже подано сложно, но все равно понял. Хороший пример такой можно привести из наследования C++. Наследуемый/родительский тип всегда меньше чем дочерний, поскольку дочерний содержит и данные родителя и свои уникальные. По этой логике Красноярский край является подтипом города Красноярска. С lifetype subtyping та же логика. В растономиконе, тоже пример был географический.
Оговорка )
31:45 "Если индекс 1 и индекс мут равны...", а должно быть "если индекс 1 и индекс 2 равны..."
В примере с реализацией IterMut из слайса с сырыми указателями begin и end в состоянии не очень понятно, откуда берется гарантия, что их потом можно разыменовывать. Хоть они и не объявлены как pub, их все равно хотя бы в текущем модуле можно изменить на произвольные значения, для чего unsafe не потребуется. А вот метод, который их будет в unsafe разыменовывать, получается что должен полагаться на корректность кода в safe (или даже на отсутствие такого кода), что как бы противоречит первоначальной идее. В более общем случае с сырыми указателями возникают новые инварианты, которые unsafe код не может проверить, а safe код может нарушить. Что-то ключевое в понимании этой философии у меня ускользает.
Идея в том, что unsafe распространяется на весь модуль. Так что да, unsafe полагается на соседний safe код и наоборот. Поэтому нужно стараться изолировать unsafe код в как можно более простом и маленьком модуле. Подробно про это рассказывается на следующей лекции
@@nanoqsh да, спасибо. Следующая лекция и правда ответила на мой вопрос.
идеологически, почти, unsafe выполняет роль io в хаскеле)
Не уверн, что соглашусь -- для хаскелевского IO нет аналога safe abstraction. Нельзя оберунть заражённый IO интерфейс в sans-IO.
А главная мысль растового usnafe как раз в том, что сверху unsafe можно сделать не-usnafe абстракцию.
Тут аналогия скорее с unsafePerformIO.
Просто любопытно, а есть те кто понял про "вариантность"? Часто даже слова разобрать невозможно...
Если предварительно что-нибудь посмотреть на эту тему - то понять можно, хотя бы частично. Вот тут разжевано про вариантность в Java: th-cam.com/video/tlAGSScIu_w/w-d-xo.html
Возможно кому-то поможет: ru.wikipedia.org/wiki/Ковариантность_и_контравариантность_(программирование)
Сразу понятно почему не стал объяснять контравариантность ф-ии по аргументу и результату. Ну это же очевидно. А почему не объяснил? Потому что вообще не раскрыл термин variance который можно просто стащить с rustonomicon-а