Yeah, that's the F# support for it. The interesting bit is that C# supports much nearly the same query syntax (`for item in something where item.IsInteresting select new { name = item.Name }`) and secretly supports just about any arbitrary Monad you want to write [1]. Just as C# also was one of the first languages to take something like F#'s async { } builder for async/await syntax, as a different Monad transformer (that C# also built to be duck-typable for any Monad that fits the right pattern).

LINQ and async/await alone can be heady "gateway drugs" in C# to learning functional programming fundamentals (including the deep, advanced fundamentals like Monads), and C# only seems to continue to pick up little bits of FP here and there over time.

There are definitely lots of reasons why even some of the biggest FP fans often think "C# is good enough" without needing to reach for F# in 2023. (Which is why the post here, and the comments above in this same thread lament that F#'s biggest problem is the shadow that C# casts.)

[1] Mark Seemann did an entire series of blog post on coding common Monads in both F# and C# and the C# code is very interesting at times: https://blog.ploeh.dk/archive/