Why the T in query_map, and query_and_then is constrained with 'static? about rusqlite HOT 3 CLOSED

Hmm, yeah, I think you're right. The intent was to make sure the caller couldn't collect the SqliteRow handles being passed into the closure; e.g.,

let rows = query.query_map(&[], |row| row);

but even without the T: 'static I don't think it's possible to get this to compile. I wonder if a solution to this open bug (related to this SO question about closures that return references) would make it possible to write this, at which point the T: 'static would no longer be redundant. What do you think?

from rusqlite.

Oh, now I see the reason of that static. But the worst thing that would happen, if somebody's collected these rows, would be just a panic, nothing more, right?

So if the 'static were removed, the bug (still not fixed 😞) wouldn't prevent returning rows from a closure (the workarounds are really simple (create standalone fn or just don't use annotations)).

But I think there's a way to prevent collecting rows without restricting T! I you'd change the F type inside MappedRows from FnMut(SqliteRow) -> T to FnMut(&SqliteRow) -> T, Rust would naturally prevent the short-lived reference from escaping the closure body. And since SqliteRow is not Copy, then no panics guaranteed! (expect of somebody calling .get(999) of course.

from rusqlite.

But the worst thing that would happen, if somebody's collected these rows, would be just a panic, nothing more, right?

Correct. And actually just collecting them is fine; it'd just panic if someone tried to use a collected row other than the last one.

I you'd change the F type inside MappedRows from FnMut(SqliteRow) -> T to FnMut(&SqliteRow) -> T, Rust would naturally prevent the short-lived reference from escaping the closure body.

Ahh, that's a great point. Will make that change shortly.

from rusqlite.