Jann HornFeb 23
normal C: the programmer will write what type they want, easy
C++: we're fancy, the compiler can, like, infer type stuff on the left side of an assignment based on the type on the right side! it might make it a little harder to figure out stuff like iterator types without a fancy IDE but it will be worth the convenience if the feature isn't overused
Rust: you're like a baby, hold my beer, we will infer part of the type of a variable based on WHAT HAPPENS DOZENS OF STATEMENTS FURTHER DOWN mwahaHAHAHAHAHA good luck trying to read this code in one pass suckers
Show threadJann HornFeb 23
in rust it is apparently normal that you can create a vector, call functions on it that resize it and whatnot, and then later insert elements, and the element insertion implicitly provides the type and element size needed to compile preceding method calls
Show threadSiguzaFeb 23
@jann I was recently pointed at this, and it scares me: https://github.com/Speykious/cve-rs/blob/main/src/lifetime_expansion.rs#L61
Show threadJann HornFeb 23
@siguza I'm not fluent enough in rust to understand any of what's going on there
Show threadSiguzaFeb 23
@jann neither am I, but apparently it's a soundness bug in the Rust compiler (or the specitself?), first reported over 10 years ago, and still unsolved as of today :) https://github.com/rust-lang/rust/issues/25860
Implied bounds on nested references + variance = soundness hole · Issue #25860 · rust-lang/rust

The combination of variance and implied bounds for nested references opens a hole in the current type system: static UNIT: &'static &'static () = &&(); fn foo<'a, 'b, T>(_: &'a &'b (), v: &'b T) ->...

GitHub
Show threadburakemirFeb 23
@siguza @jann There was a lot of work done around generics and lifetime parameters, including language changes, and I'd venture to say there is still willingness to solve it.
Show threadburakemirFeb 23
@siguza @jann wait, also this commit from Oct 2025 says it is fixed: https://github.com/kstrafe/rust/commit/7f689bfb0b2774d1ea94c5ce6b9b58bbfeb95bc0
Fix unsound lifetime extension in HRTB function pointer coercion · kstrafe/rust@7f689bf

Fixes #25860 = Problem = The compiler allowed unsound coercions from function items/pointers with nested reference parameters to HRTB function pointers, enabling arbitrary lifetime extension to &...

GitHub
Show threadSiguzaFeb 23

@burakemir @jann and where does this commit... live? GH tells me:

This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.

(Your link is for kstrafe/rust, but same goes for rust-lang/rust.)

Show threadburakemir
@siguza @jann Here is the discussion https://github.com/rust-lang/rust/pull/147543 apparently not a full fix. But... evidence of willingness to fix 😉
cve-rs: Fix unsound lifetime extension in HRTB function pointer coercion by kstrafe · Pull Request #147543 · rust-lang/rust

Doesn't fix but slightly patches #25860 = Problem = The compiler allowed unsound coercions from function items/pointers with nested reference parameters to HRTB function pointers, enabling arbi...

GitHub
Feb 23 at 11:06pmWeb
Show threadSiguzaFeb 23

@burakemir @jann oh yeah, I assumed there was willingness to fix.

I just said it scares me because this feel like the kind of issue that requires you to potentially invent new math...

Show threadburakemirFeb 24
@siguza @jann Yeah, I understand the concern. The cve-rs unsoundness is not due to the type system unsoundness (the math being wrong) but due to the implementation not checking enough. This is addressed by the new trait solver, which is a declarative model (chalk, logic programming with hereditary Harrop formulas) and its implementation, which has taken years and should land this year. So the math is already there, the implementation is almost there. That is what I meant by willingness to fix, the fix is actually work in progress.