Rust 1.72.0

[@Benni1000games]

I assume the endian lints have been added so you can discourage people from accidentially breaking portability between platforms by them assuming something will use BE or LE down the line. Like using to_be_bytes and then using that result somewhere the native platform expects LE byte order

[@zperk13]

Yep! I was working on a network protocol, and two computers communicating could be using different endianness, so you don't want to use native endianness in that. Also, it's possible to accidently type (especially with code completion) the wrong one. For instance, in my thing, I'm always using little endian, but maybe while typing fast and using code completion, I accidently type big endian instead. If that happened, this lint would stop me.

[@NathanStocks]

@@zperk13 I love that you found this video and filled us in on the details! 😄

[@birraasmile9722]

Thanks Nathan for all your videos that relates to new version of Rust and its top additions/changes

[@NathanStocks]

You're welcome!

[@Dygear]

As far as the ne/le/be lint -- The use case that comes to mind is a byte format for a file or network stream that you want to ensure is consistent. Having a Raspberry Pi talk to a Windows machine, you want to make sure the byte order is consistent between these two different archs and their different byte orders. In theory, everything over the wire would be translated to network byte order, but I don't think that is guaranteed.

[@zperk13]

Yep! I was working on a network protocol when I suggested the lint

[@NathanStocks]

@@zperk13 Just out of curiosity, can you share what network protocol you were working on?

[@zperk13]

@@NathanStocks I was just experimenting with tcp hole punching. Nothing formal/official

[@NathanStocks]

@@zperk13 Cool, thanks for sharing!

[@zperk13]

14:20 Yay! It made it in! I had a non-zero amount of influence on that. To answer your question as to why: I was working on a communication protocol between computers and in it, I needed to decode/encode information, and to do that, I needed to convert multiple bytes into one integer. Now, if you're doing this, it's very important that you always use the same endianness when encoding/decoding, and it's possible you could mess that up. So in my thing, I used little endian. If at some point I accidently used big endian, which would make the encoder encode stuff wrong, now clippy can warn me!

[@NathanStocks]

Ah! Thank you for the explanation!

[@realth000]

24 new lints, that's why I love clippy

[@NathanStocks]

Seriously, it's so good.

[@RenderingUser]

Damn. This is a sentence that would have been entirely unimaginable almost 2 decades ago.

[@NathanStocks]

​@@RenderingUser 🤣Seriously. The original clippy that it is named after was a disaster!

[@NathanStocks]

Seriously, the *other* clippy from long ago was...not well loved.

[@meka4996]

Thank you!

[@NathanStocks]

You're welcome!

[@Dygear]

I've never used Manually Drop before -- So the underlying details are not known to me at this time -- I would have thought that dropping with the drop function would actually cause the drop to happen ... Whereas it going out of scope would _not_ drop it because there was no manual drop statement there. I believe this is due to the ManuallyDrop value actually belonging to the interior of the Struct, but I do think that intiatively a drop function should work on ManuallyDrop. I would love to know why that was actually not considered acceptable or if it's a language limitation.

[@NathanStocks]

The ManuallyDrop struct is "A wrapper to inhibit compiler from automatically calling T’s destructor." -- so whether you explicitly drop it inline with the drop() function or let it go out of scope makes no difference. For more details, check out doc.rust-lang.org/stable/std/mem/struct.ManuallyDrop.html

[@TehGettinq]

thanks!

[@NathanStocks]

No problem!

[@meowsqueak]

Returning Ok on an unsuccessful kill seems like a Bad Idea to me. It assumes that kill is only used to terminate a process. But what if it's useful to know whether a process was actually killed or not? This is throwing away information. EDIT: oh, it's due to a Windows compatibility thing. Great 😕

[@NathanStocks]

If you want to know the status of the child process (whether it has already exited), call try_wait. doc.rust-lang.org/std/process/struct.Child.html#method.try_wait