Add syntactic sugar for conditions.

[polo-asm]

Many conditions can become more readable with some syntactic sugar.

Add on boolean :

.where_col( |a| a.is_active.is_true()) )

.where_col( |a| a.is_admin.is_false()) )

Add on optional:

.where_col( |a| a.address_id.is_none()) ) # or is_null ?

.where_col( |a| a.address_id.is_some()) ) # or is_not_null ?

To inverse any condition

.where_col( |a| Not( a.day.in_list('Monday','Tuesday') ) ) 
// or :
.where_col( |a| a.day.not().in_list('Monday','Tuesday') ) 

Whate do you think about all theses examples? Do you think that some of them are useful?

[dbxfb]

.where_col( |a| a.is_active.is_true()) )
.where_col( |a| a.address_id.is_none()) ) # or is_null ?
.where_col( |a| a.address_id.is_some()) ) # or is_not_null ?

this is quite subjective, but I don’t think these are a lot more legible than equal(true), equal(None) and not_equal(None). Increasing the API surface also creates cognitive overheads, and I would argue the current design strikes a good balance there.

I would argue against is_null/is_not_null since Welds provides fluent types and naming for Rust, I think maintaining the high level façade outside of the manual SQL escape hatch makes for a very pleasant devX.

.where_col( |a| a.day.not().in_list('Monday','Tuesday') )

on that last example, we currently have equal and not_equal: adding a not_in_list would be more consistent. this encourages people to write positive clauses rather than negated ones: for example .not().lt(5) is less legible than .gte(5) IMO. tangentially, it also requires less typing.