Safe Rust AIN'T SAFE!? (cve-rs) 

Not able to play either video. Just get a generic error.

@@brandonlewis2599 Huh, it works fine for me.

walking _dead

If you said this out loud before a non-technical person, they would've literally started thinking that we programmers are doing dark magic

Thanks, glad to hear it!

See my part 2 video - ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-fdu6OcQX5gE.html You very much can do it one step at a time, explicitly laying out all the types, and the borrowck is none the wiser. ;)

I feel like what's up here is that weird should be a function that has a bound 'a : 'b, which can be thought of as an extra argument that it needs to accept as a proof that a outlives b (just like when a function has a bound that T: Display, you can think of it as accepting the actual implementation of T being Display as an argument). Then the type &'b&'a() isn't actually carrying that proof, it must be carried separately.

@@jfb- This is a really good thought- traits are secretly just implicit parameters that the compiler can pass for you. In for example the Scala language it doesn’t have traits natively but you can get them this way, because it does let you mark parameters as implicit and the compiler will figure them out. So the function really needs to accept some sort of proof that `'a: 'b` as an argument. Rust sort of pretends like `&'b &'a ()` does this but it doesn’t. Because any `&'b &'static ()` is clearly an `&'b &'a ()`, but a proof that `'static: 'b` is clearly *not* a proof that `'a: 'b`. I really like that actually. :)

Imagine a function that takes a proof that `a

@@residual-entropy Traits could in theory just be implicit parameters that the compiler passes for but that's actually not how rustc implements them unless you use the `dyn` keyword.

It didn't- as far as I can tell the `cve-rs` project got up high on Hacker News. Assuming I'm not misremembering it was locked for spam before my video.

Thank you so much! :)

Glad you liked it! You’re right that it seems very unlikely to create by accident, but I hate to say I don’t think you’re wrong about it being introduced by accident being totally impossible either.

This is the way. ;)

Thanks, glad you enjoyed it! :)

Glad you liked it! :)

That’s the idea ;)

Thanks for that, glad you liked it!

Thanks! Glad you liked my questionable explanation lol. :)

It is interesting given some languages like Haskell don’t have subtyping at all.

Thanks, glad you enjoyed it!

Thanks, glad it worked for you! :)

Yes that’s right but the trick is how do you remember those conditions. Really the type of `weird` should be something like `for where 'a: 'b fn(…) -> …`. But that type currently doesn’t exist, so you’d have to add that to the language.

Actually Rust’s `Vec` type is covariant! You can find this here: doc.rust-lang.org/nightly/nomicon/subtyping.html Because of Rust’s borrowing rules you can only have one mutable reference, so it’s actually fine for it to be covariant. If you want it to behave more normally you would have to use an interior mutability type like `Cell`- those actually are invariant.

​@@residual-entropyThen it should not be. It is not fine. If I define a function that accepts a Vec and you pass it Vec and the function adds a dog to it, what do you have?

@@a46475 To add stuff to it you need to have a mutable reference to it (`&mut Vec`). Mutable references are invariant (and this is why).

@@residual-entropy oh ok

It sounds like you’re describing reference counting to manage memory. This is a thing (it’s what swift does), every pointer also has a reference count, which is incremented when a reference is created, decremented when the object goes out of scope, and when it’s zero you free the object. You can create a reference counted pointer in Rust with the `Rc` type. Reference counting everything (like swift afaik) has pretty crappy performance, Rust is trying to get the same speed as C and C++. All this incrementing/decrementing takes time, and more importantly it also is very cache-unfriendly (you can google more I don’t think I can explain it in a yt comment if you don’t know). But regardless, the point is that reference counting is slow- it can actually be slower than full on garbage collection like most languages have. Hopefully that clears things up a bit. :)

Thanks!

Thanks! It’s not that every lifetime is a subtype (sublifetime really) of 'static - it’s that 'static is a subtype of every lifetime. But yeah, this is essentially a hole where that’s not the case - nested references hide additional constraints you’re dropping. Again tho ideally (and if you don’t want to break existing code) those extra constraints should be separate from the reference type itself. Then it would be totally correct to say &'static T is a subtype of &'a T for any T and 'a.

Thanks, glad you liked it!!!

@@residual-entropyGonna check the Bad Apple one now.

Thanks!

Hold up I only just realized that you're the one who actually made cve-rs lmao. I swear I was just like "that name seems familiar" and then moved on. Thanks for the kind words *and* for making the crate! :)

​@@residual-entropyYou're welcome haha. To be completely honest I only did a third of the work (for example Creative0708 iterated on all the safe transmute implementations) and the license we chose mostly reflects the amount of understanding we actually had when making this. To me there was a problem mostly with lifetimes, but you explained how variance plays into it and I can say you made me understand the exploit better than I did before lol

@@Speykious Thanks for clarifying, but also it’s really quite cool to hear that I made it make more sense to even you lol. :)

Not quite- we aren’t substituting 'a and 'b but we’re just using the subtyping relationship. It’s like converting an `fn(Animal, Animal)` to an `fn(Cat, Animal)`. We aren’t substituting `Cat` for `Animal` we’re just narrowing a type that’s in a contravariant position. I made a part 2 with more detail (which kind of is necessary to understand how to fix it): ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-fdu6OcQX5gE.html Hopefully that helps clear things up.

They can’t, see part 2: m.ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-fdu6OcQX5gE.html

Thanks! :)

Glad you enjoyed it! :)

Thanks, glad it made sense! :)

Glad you liked it :)

Thanks, I’m so glad you liked it! :)

I’m using the Moegi Dark theme, as for the font it’s just the default which I think is Droid Sans Mono.

So 'a is not 'static, in fact the only bound checked is that ‘static: 'a (well and 'static: 'b). All that needs to happen is for any `&'static &'static ()` to be a valid `&'b &'a ()`, *regardless of what 'a and 'b are*. I really can see why this is confusing, the important thing is where 'a and 'b come from. They are given to the function, when you say `fn extend…` you are saying “for any 'a and 'b you give me, …”. So the compiler when doing variance checks looks to see if `&’static &'static ()` is a subtype of `&'b &'a ()`, which it is for any 'a and 'b. So the conversion is allowed. Someone else said kind of the same thing, we’re never choosing what 'a and 'b are or constraining them inside the definition of `extend`. Sorry for not being clearer about that in the video, hopefully this clears it up a little. :)

@@residual-entropy No need to be sorry. Your video still did a lot for me to help me understand how this works. I guess I'm just a little frustrated that I don't understand why the compiler can't catch this :).

​@@IsawU I'm glad the video was able to help at least some. :) The full chain goes something like this: 1. We start with the function `weird`, which is a function declared as `fn weird(...: &'b &'a T, ...: &'a T) -> &b T`. The compiler at this point can tell that if you call `weird(...)` it has to check `'a: 'b`. 2. We put it in a variable, so now `weird` is an actual value with a type. The function `weird` works for any 'a and any 'b, so we give it the type `for fn(&'b1 &'a1 (), &'a1 T) -> &'b1 T`. (This weird `for` is called an HRTB). This is where the bug is - we've silently dropped the constraint that `'a1: 'b1` whenever you call this. It's also why fixing this is very much nontrivial - where does this constraint even go? Creating a type like `for where 'a1: 'b1 fn(...) -> ...` isn't something you can do in Rust (right now, adding this would allow you to fix it). 4. The compiler chooses 'a1 to be 'a and 'b1 to 'b. But by this point the constraint that `'a1: 'b1` is gone, and so we never know to check `'a: 'b`. It now has the more refined type `fn(&'b &'a (), &'a T) -> &'b T`. 5. We play the contravariance card and turn it into a function that takes an `&'b &'a ()` into a function that takes an `&'static &'static ()`. We now have `weird_function`. Hopefully that helps. :)

If you want to learn about how you might fix it (it’s not quite so easy)- there might just be a part 2 video on the subject ;) ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-fdu6OcQX5gE.html

Done! :)

Nice conclusion, but in the beginning it sounded like you were talking about @residual-entropy . (Got no idea how to mention someone on RU-vid though)

I didn’t think it was referencing me- but maybe I’m just naive lol. Last year I did a microarchitectural security project. You can trust me when I say I am very much aware of the fact that nothing is perfectly secure and all we can do is mitigate to the best of our ability. That said I do think using Rust is a pretty good mitigation tbh. ;) (btw you didn’t mention me but I don’t know how to either lol- fortunately I spend too much of my time reading comments lol)

@@residual-entropyApparently it works on replies (although I didn't get the same mention when replying to the other guy). Though I wonder what you think of Zig? Seems memory-safe too, but not as safe in return for a lot more simplicity. Would love it if you make a video about this.

@@khalloof Do not worry. I absolutely love Zig and have a lot to say about it- a video is very much coming once I finish the couple I’m working on right now. ;)

Thanks! :)

Glad you liked it. :) The compiler first has to figure out the type of just `weird`, which it can happily infer as `fn(&'b &'a (), &'a T) -> &'b T`. Then when we define `weird_function` we aren’t saying “okay change 'a and 'b to 'static”. We’re saying “hey can I give you an `&'static &'static ()` instead of an `&'b &'a ()`” and this is totally fine. We aren’t ever defining 'a or 'b inside the function, when you say `fn extend…` you’re saying this function will work for any 'a and any 'b (chosen when you call it). But the compiler knows that a `&’static &’static ()` will always count as a `&'b &'a ()` no matter what 'a and 'b are. Hopefully that made sense, let me know if it didn’t or you have other questions. :)

@@residual-entropy If possible start Rust tutorial series like crust in rust by Jon Gjengset. You have lots in your head that other would like to hear about it.

@@AlexKen-zv8mm Thanks for the suggestion, I just might give that a try.

@@residual-entropyyou should , take your time, enjoy it.

Just a bit- I felt like I was talking too slow but I’m not going to keep doing that or anything.

@@residual-entropyPlease don’t speed it up like this in future videos. I found it very off-putting and hard to understand in places.

@@Tombsar I won’t.

See description for a link to the issue. There’s no clear way to fix it without either making massive changes to the Rust compiler or adding a new language feature.

Well this is advanced stuff you probably shouldn’t do lol, I wouldn’t be discouraged to learn the language because some crazy type system issue doesn’t make sense. Btw someone else commented on the part 2 video where I said “'twas” that they thought 'twas was a lifetime lol. ;)

Same... Although I love template metaprogramming in C++ to a point where my code sometimes looks like alien language... So... I guess I'm a little hypocritical.

@@noxagonal Hey, I’ve written some heinous stuff with C++ templates, type traits, concepts, and decltype/declval. It’s fun and seems like your making progress but usually I get to the end and realize that I didn’t actually need all that chaos lol.

@@residual-entropy I understand. The truth is, that I've never had to deal with lifetimes in my rust journey, is that kind of thing that you know it's there if the situation requires it

@@Otakutaru You will one day- and you’ll have the wonderful privilege of not needing to know all the crazy details like you do for this bug. ;) Best of luck on your Rust journey tho! :)

There's only one 'a which is the one passed to the `extend` function. For simplicity let's call the lifetimes 'a and 'b in the definition of `weird` 'a1 and 'b1. So pretend we said `fn weird(...) ...`. When creating `weird_function` the compiler needs to see if we're allowed to convert a `for fn(&'b1 &'a1 (), &'a1 T) -> &'b1 T` to a `fn(&'static &'static (), &'a T) -> &'b T`. The weird `for` bit is called a Higher Rank Trait Bound or HRTB, and basically just says "for any 'a1 or 'b1 you give me ...". The compiler chooses 'a1 to be 'a and 'b1 to be 'b, and so now we just have to convert `fn(&'b &'a (), &'a T) -> &'b T` to `fn(&'static &'static (), &'a T) -> &'b T` which it can. So now we call the function, the compiler checks that `FOREVER` is a `&'static &'static ()` which it is and so that part is fine. And then it checks that `borrow` is a `&'a T` which it so we're all good. So the choice of 'a1 and 'b1 (which in the original code are 'a and 'b inside the definition of `weird`) is done explicitly by us when we say `let weird_function: ... = ...;`. The 'a and 'b in `fn(&'static &'static (), &'a T) -> &'b T` refer specifically to the 'a and 'b for the `extend` function. Let me know if that doesn't make sense (this stuff definitely is weird). :)

​@@residual-entropy It doesn't make sense to me. The line: let weird_function: fn(&'static &'static (), &'a T) -> &'b T = weird; seems to obviously require that &'a is at least as long-lived as &'static, because otherwise it would not be compatible with weird's signature. According to weird's signature: fn weird(_witness: &'b &'a (), borrow: &'a T) -> &'b T { It is obvious that the lifetime of weird's second argument must be the same as or longer than the lifetime of weird's first argument. So in weird_function's type let weird_function: fn(&'static &'static (), &'a T) -> &'b T = weird; the second argument &'a T must have a lifetime longer-or-the-same as the first argument which is &'static. So why does the compiler allow calling weird_function with a second argument that has a lifetime shorter than &'static ?

Moegi Dark :)

I'm a fan of propositional logic and notation too, but that would probably just be confusing to most people, and also I don't really know of a standard syntax for things like lifetimes that are Rust-specific. Those might exist but I mean even if they do almost nobody would recognize them.

Polonius (NLLs) is about making the lifetime system *more* accepting. If you’re curious to learn more and also understand how to fix it boy do I have the part 2 video for you: m.ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-fdu6OcQX5gE.html ;)

nevermind, i see your second video lol

I made a part 2 video which explains the ideal fix ( ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-fdu6OcQX5gE.html ), BUT basically you want to be able to encode the constraint that 'a: 'b in the function type itself.

A couple things: - Returns are covariant not invariant but I’ll assume that was a typo - The actual issue here isn’t that you can do contravariance with lifetimes (although disallowing this was proposed as a short-term fix) - I’m not sure what you mean by “the lifetime has to be changed”? Changed how? The lifetime is “changed” in the sense that it’s converted from `&'b &'a ()` to `&'static &'static ()` which is totally fine, but the hidden constraint that `'a: 'b` was dropped. How would you change the lifetime to keep that constraint alive? Sorry if things were confusing.

@@residual-entropy I'm beginning to see why this hasn't been resolved in a decade. Is there a proposed alternative fix?

@@torsten_dev If you read through the issue you can see that the sort of ideal solution is to allow constraints to be added to function traits and then to have these constraints be automatically generated as necessary. The type of `weird` is currently `for fn(&'b &'a …) -> …` but the idea is to change it to `for where 'a: 'b fn(&'b &'a …) -> …`. The `for` bit exists and is called a Higher-Rank Trait Bound or HRTB. Basically it just says “hey when you actually use this type you gotta give me a 'a and a 'b.” The proposal is to add `where` clauses to this expression. Then when you actually sub in 'a and 'b from the `extend` function you would know to check `'a: 'b`. Of course this already involves creating a new language feature that extends an already-complicated language feature (HRTBs). You would even (hypothetically if it were implemented) be able to have lifetime where clauses inside of type where clauses like: `… where T: for

@@residual-entropy I remember wanting to use HRTBs for an associated type trait A where 'b: 'a }. (type B is only defined for lifetimes that outlive 'a) and it didn't work but I didn't expect the current implementation to be unsound. I would probably prefer if they wouldn't allow dropping implied constraints and went with the largest supported type instead.

​@@torsten_dev developers said that solution of this problem relies on features of new rustc type checker which is still in development.

Hey, I did put "under very specific circumstances usually its fine" in the thumbnail. Obviously everyone noticed that. /s

Thanks, glad you liked it. :)

Thanks! There really wasn’t much too it- I just screen-recorded vscode in zen mode for the actual coding parts, and then I used kdenlive to edit everything. The VO was recorded on my phone resting on top of a bunch of small boxes so that it was just above like where my laptop webcam is.

:)

Lifetimes don't behave like types in a very specific way. I made a Part 2 video that explains this in more detail (including the specific way in which types and lifetimes behave differently). ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-fdu6OcQX5gE.html

*sigh* Sure Rust isn’t that popular but it’s been growing fast and it’s definitely more than just a few people. And yeah it’s not a serious security exploit- but it’s still a problem. And I’m not sure what server-side has to do with it not being a problem, if this ends up in some library that your server users now you’re back to the same world as broken c code where you can read loads of uninitialized memory and probably rce if you’re clever about it.

If we keep things as they are then, well, yes the conversion is invalid. The thing is that this is simply the result of borrows being covariant in their lifetimes- `S: T` implies `&’q S: &’q T`. So (*if* you don’t implement the proposed fix and you’re forced to have a constraint `'x: 'y`, then we have no problems. The thing is if we run with your version and say that borrows *aren’t* covariant that’s a pretty basic assumption and that would require reworking loads of stuff in the compiler and breaking heaps of existing code. So yes that conversion is incorrect but only if we assume the prior step isn’t. Hopefully that makes sense. :)

I do hope that this gets fixed and I fully believe that eventually they’ll get around to it. It’s just that a ton of people see this as something with an “easy fix” and I wanted to clarify that that just isn’t the case here.

We aren’t substituting 'a for 'static, we’re just using subtyping. It’s fine to convert an `fn(Animal, Animal)` to an `fn(Cat, Animal)`. If you want to see it step by step also there’s a part 2 video: m.ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-fdu6OcQX5gE.html

I was actually going to add that but the video was getting kind of long and I wanted to get back to working on the next one, that’s all. Maybe I’ll make a little bonus video with it if I have some time- thanks for the feedback tho.

@@residual-entropy this was a really great vid, would love to see another on transmute when you have time!

Ask and you shall receive (sometimes): ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-qqgDuEi7OU0.html

Ask and you shall receive (sometimes): ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-qqgDuEi7OU0.html

The issue was opened in 2015 and NLLs were stable in 2022 so I’m pretty sure it did. :)

@@residual-entropy cranelift, gcc?

I’m not familiar with cranelift and am not sure what you mean by gcc? I don’t think it depends on the compiler backend since it’s a weakness in the type/lifetime system as it currently exists.

@@residual-entropy cranelift uses sophisticated data types to represent everything in rust typesystem, so some states theoretically cannot be represented and compiled by cranelift. gats let them represent read only/write only pointer types which cannot be casted in each other, for example. idea was featured in some twir issue, if I'm not mistaken it to some other project. gcc also has their own rust compiler but I'm unsure how featureful are they, so I wonder if it would even compile with it.

@@DeathSugar Ah, I guess in that case it could be possible for them (cranelift) to add these kinds of constraints then. Thanks for explaining it! :) As for gcc your guess is as good as mine.

Because the mic was my phone balanced on some random boxes. ;) I’ll get a real mic eventually…..

@@residual-entropy ahhhh rip, good video otherwise, I couldn’t for the life of me wrap my head around the lifetime tick marker stuff, but thats my fault lol

@@therealyojames Well I’m the one whose supposed to be explaining it lol. I tried to go through the basics but did so really quite quickly- the book might be helpful here: doc.rust-lang.org/book/ch10-03-lifetime-syntax.html Glad you still liked it tho. :)

@@residual-entropy nah you did a good job explaining it, my brain just couldnt absorb it very well because I’m sleep deprived rn 😂

@@therealyojames Dw I’m a college student doing a double major- I’m always sleep-deprived. ;)

Yeah I made the mistake of speeding it up a bit since I got nervous I was speaking too slowly. Sorry.

Implementing this stuff at the hardware level doesn’t guarantee anything will be totally safe either- some ARM chips have pointer authentication but then some people used side channels to crack it: pacmanattack.com I’ve actually played around with microarchitectural security and implemented an attack known as website fingerprinting, where JavaScript on one website uses the latency to do certain operations to guess what’s happening in another tab (usually you use an ML model). It’s not super reliable but the fact that my sketchy version with a simple decision tree and not that much data worked at all is definitely a bit scary. Solving things in hardware is definitely something that could help, especially given all the code in not-Rust, but it’s not a way out at all.

Heck no. ;) This isn’t a serious problem because the likelihood of someone doing this by accident is basically zero. But it *is* interesting (at least I think so). Go is a great language too, but you’ll definitely learn more from learning Rust in my opinion. Programming languages are a sort of perspective through which you view the world, and any day of the week I could shout from the rooftops just how valuable having the different perspectives you get from different languages can be. At least until security came and made me get down from the roof. Go and Rust are both pretty nice languages, but Go just isn’t that different from more normal languages. I 100% agree with you that having to really think about what you’re doing is a great thing. If I had a nickel for every time I spent half an hour fighting with the Rust compiler before realizing that my idea was actually just stupid…… I mean then I would be able to afford an actual microphone. Regardless hopefully that makes sense, this is absolutely 0% a reason to not use Rust. I wish you the best of luck on your Rust journey! :) I’m also happy to answer Rust (or even Go if you join the dark side :p) questions too ;) - at this point yt comments are fine and I check them regularly enough (just do it on a Rust video)

Other ppl said the same thing, back when I made this I sped it up a little because I felt like I was talking too slowly. Haven’t done it after this vid tho.

@@residual-entropy I sped up one of my videos, yeah, never again!

It’s only one way; fn(AnimalSoul) is an fn(CatSoul) but not the other way round.

It’s just sped up a little because I thought I was talking too slow. Probably wasn’t the best idea in retrospect, future stuff won’t be.

Ah yes the safest language of them all

Thanks! :)

Very much agree. :)

Yeah, the fact that the language doesn’t even have a formal specification (and they only recently started on one) has always been concerning to me in much the same vein. At least there is an effort on that front ( github.com/rust-lang/rust/issues/113527 ), but it isn’t great that we don’t even have a draft at this point. I know “probably safe” is very much not easy but the way Rust is supposed to be this rock-solid safe thing it definitely seems off to have so little in the way of formality. Just my thoughts tho.

sounds just like any other program written in C++

Have you ever read a big C code base? It's so full of macros and weird syntax that it is basically impossible to parse. You already live in the world you describe, mate.

I mean yes that's right. I like to for example use the token-pasting operator (##) in C/C++ to make macros for timing, where I can say `STARTTIMER(Something)` and `ENDTIMER(Something)` and the macro will create the `timerStart_Something` and `timerEnd_Something` variables. It's truly horrendous but especially when I'm just curious and want to try something I do it anyway. We very much do live in that world but (at least imo) part of the point of Rust is to get us out of there. Also I feel like Rust definitely gives you a sense of security where you don't even think about memory issues as a possibility (assuming you don't use unsafe), and if that becomes a *false* sense of security I would say that's definitely a problem. That's all.

@@residual-entropy Well, the presence of this bug is a problem, and hopefully gets resolved sooner rather than later. I don't think false security is a problem, tho. This can be said of any language, since any compiler can have bugs. Programming in C doesn't make a compiler bug less problematic just because C makes less guarantees. Of course, C and C++ have had years and years of people working with them and resolving bug. Also, this is the only known bug in the Rust compiler regarding safety, as far as I know. You still get a ton of benefit using Rust, and it's proven by the people actually building software with it.

@@ultrapoci the problem is that this bug exists from 2015

Yes. An `&'static &'static ()` counts as an `&'b &'a ()` even though obviously proves nothing. Really the function definition should implicitly be `fn weird(...) -> ... where 'a: 'b`, but doing that would break things because of the way storing functions in variables (or passing them around) actually works. I explain that side of things in part 2: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-fdu6OcQX5gE.html

python: is it memory safe or not? I don’t know it’s been running for three days and it’s still not done yet

Same... I've never used rust

The compiler will need to encode outlived constraints into the types of variables

@@michawhite7613 yeah, after a bit of thought I imagined something like that. I wonder if it's possible without additional syntax.

Oh boy do I have the part 2 video for you: m.ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-fdu6OcQX5gE.html

I just thought that I was talking a bit too slowly. Not something I’m going to do moving forward.

I’m aware- I was just using my phone as it’s the best I have. I will get a real mic at some point, but I mean that’s a good chunk of change.

Yes. Not something I’m going to keep doing.

I’m not sure I understand how the `let weird_function: … = weird;` line requires that 'a is at least as long as 'static. All that needs to happen is any `&'static &'static ()` needs to be an `&'b &'a ()` which of course is the case. This is function arguments being contravariant enables: We’re allowed to convert a `fn() -> …` to a `fn() -> …`. In this case `&'b &'a ()` is the general type and `&'static &’static ()` is the specific type. We aren’t trying to set 'a and 'b to 'static or anything, we’re creating a new function that does the same thing with a different type signature. If it helps imagine that I instead do this: ``` fn weird_function(witness: static &'static (), borrow: &'a T) -> &'b T { weird(make_specific(witness), borrow) } fn make_general(witness: &’static &'static ()) -> &'b &'a () { witness } ``` Hopefully that example should clearly be all above board. Contravariance is sort of a shortcut to do the same thing without actually creating a new function. That’s why contravariance is a key part of the trick- the whole `&'b &'a …` thing is normally checked at the call site (in the code above when we call `make_general`. But here we never actually have to call it. In the code above you can see that `weird` and `weird_function` *do* the same thing. So the language is perfectly happy allowing us to convert `weird` to `weird_function`. You don’t need to have a `fn make_general(cs: CatSoul) -> AnimalSoul …` and then call it explicitly. You can just convert a `fn(AnimalSoul) -> …` to a `fn(CatSoul) -> …`. Hopefully that clears it up a bit. As for explaining why fixing it is difficult that’s sort of a difficult thing to do since everyone has their own slightly different idea on how it could be fixed easily. The reason it’s hard is because there isn’t a way to fix it easily, and I video going through all the possible easy fixes that wouldn’t actually work wouldn’t be very interesting. I *might* make a follow-up video explaining one or two not-quite-correct easy fixes and then the sort of ideal way to fix it. But I’m pretty busy both with the next vid and lots of other stuff. There have been a couple of people in the comments seeming to specifically think that you’re somehow substituting 'a and 'b when you don’t. Let me know if I’m misunderstanding you though.

​@@residual-entropy I thought the original function signature fn weird(_witness: &'b &'a (), borrow: &'a T) -> &'b T { specifies &'a is at least as long as &'b. I thought you wouldn't be allowed to use contravariance to specify incompatible bounds. E.g. if the signature were fn weird(_witness: B, borrow: A) -> B { I'm pretty sure fn extend(borrow: A) -> B { let weird_function: fn(SuperA, A) -> B = weird; would not be allowed by the compiler. I just don't see the difference between this and writing the same thing with lifetimes instead of types.

@@tee1532 The original signature should specify that exact constraint but currently doesn’t. This is the real problem- the language doesn’t actually have away to associate these kinds of constraints with a function type. Ideally you’d be able to say the type is `for where 'a: 'b fn(&'b &'a (), &’a T) -> &'b T`. But currently putting a where clause there isn’t a language feature that actually exists. That’s the bug and the ideal way to fix it. Hopefully that makes sense. :)

@@residual-entropy why is it an ideal fix to require the programmer to type extra words? The compiler should currently be able to infer that constraint anyway

@tee1532 (See comment after this one first, I think this one isn’t actually answering your question) How can it infer the constraint? Are you saying that at the time we use `weird` to a `fn(…) -> …` trait object the compiler should look through the type of `weird` for any of these constraints? That seems like it would work but the problem is we don’t know what 'a and 'b are at that point. The compiler deduces the type of `weird` to be `for fn(&'b1 &'a1 (), &'a1 T) -> &'b1 T`. This is basically just abstracted over any possible lifetimes 'a1 and 'b1 ( doc.rust-lang.org/nomicon/hrtb.html ). So we can’t check it then since we don’t know what 'a1 and 'b1 are and after that the constraint 'a: 'b is nowhere to be found. Unless we somehow store it in the type. Sorry for the confusion. Honestly I’m sort of regretting not explaining the `for` bit in the video but I just realize how important it kind of just seemed like unnecessary having to explain another weird rust feature. But I think it’s clear that’s not the case.

So the real question is why are functions are coercible if every parameter by itself is coercible, if, clearly, a dependency between parameters should be respected?

I made a part 2 video which (I think) explains what you’re struggling with: m.ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-fdu6OcQX5gE.html Hope that helps. :)