Could combine that idea with changing to keyword to detach.
October 25, 2025 at 8:15 AM
Could combine that idea with changing to keyword to detach.
Why not force all captures to be named if you start enumerating any? Leave today’s inferred move as is, but make the new version explicit. If you name a single thing, you must name all. That way it’s super easy to see what’s captured and how.
October 25, 2025 at 8:14 AM
Why not force all captures to be named if you start enumerating any? Leave today’s inferred move as is, but make the new version explicit. If you name a single thing, you must name all. That way it’s super easy to see what’s captured and how.
This is to support my other #rustlang project, str0m, a Sync Sans-IO #WebRTC implementation in Rust.
There I'm currently using openssl, which is less than ideal in many ways.
crates.io/crates/str0m
There I'm currently using openssl, which is less than ideal in many ways.
crates.io/crates/str0m
crates.io: Rust Package Registry
crates.io
September 27, 2025 at 12:56 PM
This is to support my other #rustlang project, str0m, a Sync Sans-IO #WebRTC implementation in Rust.
There I'm currently using openssl, which is less than ideal in many ways.
crates.io/crates/str0m
There I'm currently using openssl, which is less than ideal in many ways.
crates.io/crates/str0m
Eurovision Song Contest contribution. That’s the line.
September 6, 2025 at 7:49 PM
Eurovision Song Contest contribution. That’s the line.
Excellent! Feedback and PRs are very welcome!
March 3, 2025 at 6:45 AM
Excellent! Feedback and PRs are very welcome!
It sounds like a threat!
February 9, 2025 at 8:10 PM
It sounds like a threat!
Are you paying your candidates to partake in this?
November 28, 2024 at 4:32 AM
Are you paying your candidates to partake in this?
As a bonus, Rust 1.80 introduced new traits that made the time crate pre version 0.3.35 impossible to compile.
To maintain MSRV 1.63, I need to lock time to =0.3.20, but that makes the project impossible to compile on Rust 1.80 or newer.
github.com/algesten/ure...
To maintain MSRV 1.63, I need to lock time to =0.3.20, but that makes the project impossible to compile on Rust 1.80 or newer.
github.com/algesten/ure...
ureq 2.x: Make MSRV 1.63 work by algesten · Pull Request #878 · algesten/ureq
Close #877
github.com
November 27, 2024 at 8:18 AM
As a bonus, Rust 1.80 introduced new traits that made the time crate pre version 0.3.35 impossible to compile.
To maintain MSRV 1.63, I need to lock time to =0.3.20, but that makes the project impossible to compile on Rust 1.80 or newer.
github.com/algesten/ure...
To maintain MSRV 1.63, I need to lock time to =0.3.20, but that makes the project impossible to compile on Rust 1.80 or newer.
github.com/algesten/ure...
"But what about Cargo.lock-files?"
As a library author, I want to uphold an MSRV at the same time as I don't want to lock down dependencies (i.e time = "=0.3.20").
These are in conflict. When a transitive dependency bumps MSRV in patch-versions, your only choice is to also bump MSRV, or lock.
As a library author, I want to uphold an MSRV at the same time as I don't want to lock down dependencies (i.e time = "=0.3.20").
These are in conflict. When a transitive dependency bumps MSRV in patch-versions, your only choice is to also bump MSRV, or lock.
November 27, 2024 at 8:18 AM
"But what about Cargo.lock-files?"
As a library author, I want to uphold an MSRV at the same time as I don't want to lock down dependencies (i.e time = "=0.3.20").
These are in conflict. When a transitive dependency bumps MSRV in patch-versions, your only choice is to also bump MSRV, or lock.
As a library author, I want to uphold an MSRV at the same time as I don't want to lock down dependencies (i.e time = "=0.3.20").
These are in conflict. When a transitive dependency bumps MSRV in patch-versions, your only choice is to also bump MSRV, or lock.