I use query builders like

val q2 = Thing.TABLE.simpleQuery {
			Thing::name eqAny listOf("thing1","thing2")
			Thing::id eq 2
		}

Do you really need something more complex than infix functions and property references? I'd say

val result: Iterable<Model> = dbConnection.where { Model::fName eq "bob" }

looks nice enough.

scala looks nice enough

what your describing is effectively breaking the AST down through some of the nifty reflection mechanisms built into kotlin --the fact that

Model::fname

is trivially converted to a

KProperty

is a really cool feature, but it doesn't go anywhere near far enough imho. When you get into queries of even minimal sophistication this is going to get ulgy

I think Jinq might actually attempt to recover your extension function

but yeah, the semantics around

inline

are likely to be a boon to kotlin that C# doesnt have

but yes @aimozg several interesting question are going to come up in this things implementation

so what the MongoDB Linq Driver does

because MongoDB is so focused on the driver side, is simply apply the filter in the drivers process space

consider

it.extensionCall() && it.age > 25

the db will apply an optimized

it.age > 25

, using whatever seocndary indexes or other DB magic it has, then send that back to the driver (the library), to apply the rest of the filter, which includes a call do your extension methods

what the SQL driver does I dont know since I havent used it

but you might see things like `OperationNotSupportException`'s

but i gotta go to a meeting

the guy who runs the fabulous adventures in coding explicitly dropped support for named-arguments from linq expressions

because the ramifications to the users of the Expression object can be too bizarre

but I still think its enormously valuable

brb meeting

Eric Lippart, head of the C# project for a while, thats his name

@pniederw regarding using macros in kotlin, I actually think Linq is a stroke of genius when it comes to macros: a huge amount of the bugs in macros comes from a failure to properly apply the front-end of a compiler; a macro author is tempted to start rooting-around in string values of source code, which is begging for disaster. But by productizing (APIzing? weaponizing?) the AST in the way microsoft did, they basically did an enormous amount of the heavy lifting needed by macros for the would-be macro author. In short, this feature would enable a huge number of macro-like functionalities without the kinds of horrifying bugs you often associate with macros.