Virgiel
Virgiel
~~I had an idea using traits in #78. We would have:~~ - StringSQL: `&str`, `String`, `Cow` - BytesSQL: `&[u8]`, `Vec`, `Cow` - ArraySQL: `&[T],` `Vec`, `Cow` ~~The problem with Trait...
We need something that works well with `Option` and arrays. And traits are a nightmare for that.
This solution does not work for params struct because of https://github.com/rust-lang/rust/issues/23246 🥲 It makes me want to remove params struct support 😒
It's impossible to support ergonomic params for composite type params struct without a deep refactoring of our type logic because they can be nested inside other params struct
On reflection, not supporting composite type params with this feature should not be a blocking problem, they are still usable, but less ergonomic. We can support them later. Having to...
This is fantastic !
Apart from two remaining limitations, the code is ready for review: - Fixing SQL and domain escape from iterators: could be solved by using a generic iterator type as we...
> Your first point (iterators and lifetimes) would, I think, require GATs, which are still a couple months away at best. Yes and this is only problematic when using an...
With this PR, the misuse of the `bind` function creates much less ergonomic errors at compile time, but is more flexible and even supports the use of iterator parameters for...
Should we make a `json` feature for the JsonSql ergonomic trait ?