It's no inconvenience. We appreciate your strong contribution to the Slick community :)! We can chat over hangout or chat if that works for you. More real time communication would help I think. In general you could sum it up like this: I think the APIs you propose work more like SQL than like Scala collections. Example: `Employees.map(_.salary)`. In Scala collections `.salary` is a single scalar value - the salary of one particular employee. Calling `.salary.avg` does not work.  `.avg` is not a method of Int. It also would not make sense for Scala collections. What's the average of one Employees salary? It's not what you meant to express. In SQL however something like this: `avg(salary)` is allowed, because in this context `salary` refers to a whole collection of salaries. So following the SQL semantics ScalaQuery actually allowed `.salary.avg`, but we decided to go a different route with Slick and aimed for Scala collections semantics: `.map(_.salary).avg`. That's what makes Slick a Scala-to-SQL compiler, not a Scala DSL for SQL. This unifies the API of Slick and Scala, which we believe is beneficial in many ways. And with new additions we want to follow this concept and ask ourselves, how can you express the desired semantics with Scala collections and what does it take to make it work in Slick. Regarding window functions, I had a chat with @szeiger and we are both under the impression, that the semantics can be expressed using groupBy and flatMap along the lines of what I wrote above. So it is in fact already possible with Scala collections. To support it in Slick we would need to allow this syntax and compile it to windows functions internally, but it wouldn't be exposed to the user that window functions are used, which is a good thing I believe, because he wouldn't have to worry about this rather obscure SQL construct and just think Scala collections. Does this make any sense :)? 

By the way, Case is one of the cases where we couldn't go with Scala syntax, because we can't overload the if-syntax, so we had to come up with our own DSL for it, but its a workaround the limitation.