frank-king: > SkiFire13: > >> I wonder how you would create an instance of `Thin`/`ErasedMetadata` though. > > By unsizing from a sized value, i.e. `impl<T: Unsize<U>, U: PointeeSized> Unsize<Thin<U>> for T {}` (probably implemented by the compiler, then `Thin` must also be a lang item) Take a second look, this question seems not so trivial. Creating a `Thin` on heap will not be a problem (just similar to `ThinBox`), but creating it on stack is more complicated. Taking `Thin<[u8]>` for example: * first, construct a sized value on stack, like `let value = [0_u8; 4]` (with type `[u8; 4]`), * second, obtain the metadata (e.g. by `let metadata = std::ptr::metadata(&value as &[u8])`), * third, combine the metadata together with the value, i.e. `let thin = Thin { metadata, data: value }`. * The problem is: what's the type of `thin`? * `Thin<[u8; 4]>`? No, `<[u8; 4] as Pointee>::Metadata` is `()` instead of `usize`; * `Thin<[u8]>`? No, it's unsized so cannot be constructed on stack. The solution I can think of is to provide a builtin-macro `thin!()`, in which `thin!([0_u8; 4] as [u8])` returns a reference to the unsized value of `&mut Thin<[u8]>`. (i.e., let the compiler handle the intermediate sized `Thin` value with the unsized metadata.)

Nadrieril: > I wonder how to get good ergonomics for this type though. E.g. `std::ptr::metadata` has to return `()`, so we'd need something else to fetch the real metadata. It breaks the fairly deep assumption that "if a value needs metadata then that metadata is stored in any pointer to it". How about providing `Thin::metadata` to fetch the metadata of a `Thin` pointer? `std::ptr::metadata` is safe and takes a raw pointer `*const T`, which doesn't fit `Thin` that requires a dereferencable pointer. impl<T: Pointee> Thin<T> { pub fn metadata(this: &Self) -> T::Metadata { this.metadata } }

I see. In that case, I don't think there would be that much of a problem in changing it (but I am not knowledgeable in these parts of the compiler) This does seem useful.

The usecase of this especially in exports by example you export everything to the crate except myprivfn and PrivateStruct. pub use crate::mymod::*!{myprivfn, PrivateStruct};

Hmm... can you suggest a usecase for this? I'm not sure where it would be useful.

Ah yes, I see `ValueSized` proposed at the end of that RFC, for types that can have their metadata computed from their value. That's what `Thin` needs.

> Especially for people relatively new to rust, I think I would prefer the default were to lint against most unwraps. @toc > I believe a better approach is to change the default lint level of `unwrap` to a warning. @jmjoy I don't think linting would solve anything. And I think the number of false positives would be huge too, as someone above me said. And furthermore, anyone with more than 6 months (or 6 hours) of experience in rust knows `unwrap` can panic. I need to stress that for me, this isn't a safety/stability issue, imho, lints or renaming would _maybe_ make programmers think a bit more about `unwrap()`s but not in any impactful way. **I think the main issue is simply that the name doesn't say what the function does.** Yeah, everyone knows it, it's easy-ish to get used to, but it's just such a perpetual thorn in my side. **I thought that's why we even have crate-scope editions? So Rust can continually improve with breaking changes without actually breaking anything?** I personally would prefer Rust's stdlib not become like C++'s with 30+ years of historical baggage. * * * > For folks maintaining older MSRVs @burntsushi Do I understand correctly that Rust's crates are edition isolated? So if a crate needs no active work, needs no new rust features, needs to just continue working, it would not need to upgrade. And newer editions crates could still use it. I feel like the answer to the stable mature maintenance-mode software issue is just _well don't upgrade editions then_ * * * I do however like the symbolic variants of `unwrap_or_panic()`, like adding `unwrap_or_unreachable()` which would be the same as unwrap_or_panic but with the symbolic difference. * * * > Another strong reason against this is the confusion that I think is likely to result. And this is especially relevant to routines like `unwrap()` and `expect()` that have pervasive usage That I understand and I think it's the single biggest reason not to change it - it would instantly invalidate `unwrap`s in like one million community tutorials, docs and resources * * * > There simply isn't _that_ much wrong with the standard library. It has plenty of small annoyances, but I don't think they add up to something significant enough for an big edition-like overhaul to be worth it. @Mara I understand, and that's fair. I would disagree but I suppose this is purely subjective. * * * > As with any proposal, we must always start with the following question: "what is the problem that people are having with Rust today?" @Noratrieb The problem _I personally_ am having is that I do not like that name. I uhhhh might not be objective. * * * > If we do want to make the developers more cautious about unwrapping, a definite solution is to invent something similar to `unsafe` keyword, for example, `may_panic`, which means the it's the developers' responsibility to make sure the code does not panic: @Evian-Zhang I would love that, unfortunately, basically everything can panic. + operator can panic in Debug. Most containers can panic on many operations (`HashMap::index`). Oh and don't forget malloc() can fail at any time, so any `T::new()` can panic. * * * > `Regex::new` isn't `const` though. It may never be. I think I could come around to your perspective if `const` were more expressive, but it's a non-starter today IMO. There's just too many things that can't reasonably be `const`. > Yeah, I'm hoping at some point `const` and future `comptime` support essentially all of Rust. > We should have good tools for correctness checking -- I'm really excited by the contracts work Didn't hear of contracts before but it looks awesome! I do believe that good `comptime` + good contracts, would get rid of like 90% uses of `unwarp()` (a number i very scientifically made up). **I believe that most reasonable uses of unwrap() should be eventually replaced by contracts or`comptime`** _However_ , there would still be cases where one would need to use `unwrap` and I still think introducing `unwrap_or_panic()` and `unwrap_or_unreachable()` would be good for the stdlib

I re-read the sized_hierarchy RFC (https://github.com/rust-lang/rfcs/pull/3729) and actually I don't think `Metadata=()`=>`Sized` holds. Indeed as you say for extern types that's not the case, so we could make it `PointeeSized` and not `MetaSized`. I wonder how to get good ergonomics for this type though. E.g. `std::ptr::metadata` has to return `()`, so we'd need something else to fetch the real metadata. It breaks the fairly deep assumption that "if a value needs metadata then that metadata is stored in any pointer to it".

Hello, everyone I have an idea to we introduce negative bounds only appear in glob imports example usage: use std::marker::*!{Unpin}; This mean import me everything from std::marker excluding Unpin, This will be very useful in some situations.

First of all, since Debug does not take mutable references or UnsafeCell, I don't think this example will require invariants checking. Secondly, since the invariants will be runtime-checked, we will be able to run them without significant overhead IMO.

Yep, that was my idea. It's just that I was wondering if we wanted this as a primitive or a struct so I left it like that. Edited my post to use LLVM intrinsics instead. (BTW, since this adds a new primitive to rust, would this technically not come under the scope of an RFC?)

Or in a more functional style: buf.get(pos..) // Alternatively: // .and_then(<[u8]>::first_chunk) .and_then(|buf| buf.first_chunk()) .map(|&array| u64::from_le_bytes(array) == 0x1234567812345678) .unwrap_or(false)

ais523: > but it would be easy to create (in an external crate or just for internal use) a `const fn` that converted a bytestring to a C string if it ended with either one or two NUL bytes (thus supporting the "NUL at the end of the file") case. The `from_bytes_until_nul` method accepts a suffix of arbitrarily many NULs which is probably good enough.

Thank you for this suggestion! I will definitely use this

Evian-Zhang: > To avoid unaligned access, I use the following code: I would suggest you stop using byte-at-a-time code, both to save yourself typing -- especially in those `u128` versions -- and because if you load the whole array at once it's more obvious to LLVM to do what you want. For example, both of these have the `cmp qword` you're looking for: #[unsafe(no_mangle)] fn u64_fetch1_simpler(buf: &[u8], pos: usize) -> bool { if let Some(after_pos) = buf.get(pos..) && let Some(array) = after_pos.first_chunk() { let target = u64::from_le_bytes(*array); target == 0x1234567812345678 } else { false } } #[unsafe(no_mangle)] fn u64_fetch2_simpler(buf: &[u8], pos: usize) -> bool { let Some(b0) = buf.get(pos) else { return false; }; // This one is redundant if *b0 != 0x78 { return false; } if let Some(after_pos) = buf.get(pos..) && let Some(array) = after_pos.first_chunk() { let target = u64::from_le_bytes(*array); target == 0x1234567812345678 } else { false } } https://rust.godbolt.org/z/aMhezxxGa

(post deleted by author)

Sorry, I meant to add a `match` to extract the answer, and a `panic` if the `match` fails, but forgot – a `panic` in a `const` block give you a compile error, so it's an easy way to get the compile-time validation you're looking for.

`CStr::from_bytes_with_nul` returns a `Result` instead of a `CStr`. Although `CStr::from_bytes_with_nul_unchecked` can be used, it is unsafe.

zackw: > How do you plan to address this? Answering out of turn, but is it by using the llvm intrinsics instead?

tczajka: > What do you suggest instead, `expect`? I'd suggest you use `#![allow(those_unwraps)]`. I expect that your codebase's use of unwrap is intentional, meaningful, and largely correct. My expectation is that most people on this forum are using `unwrap` in intentional and meaningful ways though. I have seen plenty of `unwrap`s which actually mean `todo_error_handling` and absolutely should be a warning. But they are spelled the same as the very intentional ones. I don't know exactly what the perfect state of affairs is. I do know that the current state of affairs where unwrap has multiple jointly ambiguous meanings is, well at least _suboptimal_.

ryanavella: > I tend to prefer the let-else form: > > > let Ok(x) = f() else { unreachable!() }; // Or todo!() or panic!() as appropriate > > > When I come back to my code 2+ years later, I can see the rationale behind why I introduced each divergent branch. I only use `unwrap` for the `unreachable!` case. For `todo!` I'd leave space for future code explicitly, for `panic!("...")` I'd use `expect`. So inlining `unwrap` doesn't help understanding, it always means that `None` is `unreachable!`.

I think the nightly `concat_bytes!` macro is sufficient for this: something like const { CStr::from_bytes_with_nul( concat_bytes!(include_bytes!("file.txt"), b"\0")) } This would error out if there are any NUL bytes within the file itself (including at the end), but it would be easy to create (in an external crate or just for internal use) a `const fn` that converted a bytestring to a C string if it ended with either one or two NUL bytes (thus supporting the "NUL at the end of the file") case. As such, I don't think there needs to be special-case support for this – the tools Rust already provides (or in the case of `concat_bytes!` will provide in the future) seem to be enough for this.

The Rust language provides excellent build-time embedding tools with the existing `include_str!` and `include_bytes!` macros, allowing us to embed static file content directly into the final binary. These are incredibly useful for configuration, static assets, or templates. However, when working with **Foreign Function Interfaces (FFI)** , especially those leveraging C libraries, we often encounter a common friction point: safely and efficiently embedding null-terminated C-style strings. ## The Current Situation 1. **`include_str!`** : Returns `&'static str` (a UTF-8 slice). Converting this to a safe C string (e.g., `CStr`) at runtime requires an allocation (via `CString::new`) and checks for internal null bytes, which can panic. If the included file is known to be ASCII/valid C-string data, this conversion overhead is unnecessary. 2. **`include_bytes!`** : Returns `&'static [u8]`. While this gives us the raw bytes, we still need to manually verify it is null-terminated and safely create a `&'static core::ffi::CStr` from it, often requiring `unsafe` code and careful handling of the final null byte. ## The Case for `include_c_str!` I propose adding a new macro, `include_c_str!`, that would work as follows: * **Signature:** It would take a file path literal, similar to the existing macros. // Example usage: let c_string: &'static core::ffi::CStr = include_c_str!("path/to/my_c_string.txt"); * **Return Type:** It would return a `&'static core::ffi::CStr`. * **Compile-Time Guarantee:** The macro would perform **compile-time validation** on the file's contents to ensure: 1. The file contains no internal null bytes (`\0`) other than the optional, final terminator. 2. The file is properly **null-terminated**. If the file itself is not null-terminated, the macro should potentially append a null byte during embedding. 3. If any of these conditions are violated, the compilation should **fail** with a descriptive error. ## Benefits * **Safety & Ergonomics:** Eliminates the need for manual `unsafe` code to convert raw bytes or runtime `CString` allocation/error handling when dealing with embedded C-style strings. * **Performance:** Provides zero-cost abstraction for passing static C strings to FFI functions. * **Clarity:** Clearly expresses the intent of embedding a file specifically as a static C string. This addition would provide a complete set of static file inclusion tools for the most common embedded data types in Rust: Macro | Return Type | Use Case ---|---|--- `include_bytes!` | `&'static [u8]` | Arbitrary binary data. `include_str!` | `&'static str` | UTF-8 text. **`include_c_str!`** | **`&'static core::ffi::CStr`** | **Null-terminated C-style strings.** What are your thoughts on this proposal? Would this improve your FFI workflow?

> What happens if you move the b0 check after the let/else and remove the first redundant check and `buf.get?` Rust code: fn u64_fetch3(buf: &[u8], pos: usize) -> bool { let Some([b0, b1, b2, b3, b4, b5, b6, b7]) = buf.get(pos..(pos + 8)) else { return false; }; if *b0 != 0x78 { return false; } let target = u64::from_le_bytes([*b0, *b1, *b2, *b3, *b4, *b5, *b6, *b7]); target == 0x1234567812345678 } > what happens if you include the test it in the match? Rust code: fn u64_fetch4(buf: &[u8], pos: usize) -> bool { let Some([b0 @ 0x78, b1, b2, b3, b4, b5, b6, b7]) = buf.get(pos..(pos + 8)) else { return false; }; let target = u64::from_le_bytes([*b0, *b1, *b2, *b3, *b4, *b5, *b6, *b7]); target == 0x1234567812345678 } Both of the above Rust codes generate the same assembly: u64_fetch3: cmp rdx, -8 setae al lea rcx, [rdx + 8] cmp rcx, rsi seta cl or cl, al jne .LBB4_1 cmp byte ptr [rdi + rdx], 120 jne .LBB4_1 movzx eax, byte ptr [rdi + rdx + 1] movzx ecx, byte ptr [rdi + rdx + 2] mov esi, dword ptr [rdi + rdx + 4] shl rsi, 32 movzx edx, byte ptr [rdi + rdx + 3] shl edx, 24 shl ecx, 16 shl eax, 8 or eax, ecx or eax, edx or rax, rsi movabs rcx, 1311768465173140992 cmp rax, rcx sete al ret Still five memory accesses. > you can also give a name for the whole array to avoid repetition when passing to from_bytes Thank you very much for this suggestion! But I rarely use this feature, could you give me an example about how to write such code?

tczajka: > With a lint, I think all 40 of these uses would be false positives. What do you suggest instead, `expect`? This likely wouldn't replace all of your use cases, but I tend to prefer the let-else form: let Ok(x) = f() else { unreachable!() }; // Or todo!() or panic!() as appropriate When I come back to my code 2+ years later, I can see the rationale behind why I introduced each divergent branch. It is hard to say the same about `unwrap`, unless if you add comments at each `unwrap`-site. At that point you may as well use `expect` or let-else.