Brad Wilson
Urs Enzler 🐉@bradwilson @xunit yes, no Roslyn in F#.
@UrsEnzler @xunit Which means I either:
1. Don't support F# in @xunit v3
2. Don't support NativeAOT
3. Leave both systems in place, bloating the code and the maintenance burden (and having potentially different behavior, intentional or otherwise, between the two systems)
Ugh. 😔
@bradwilson @xunit as an F# dev,. I hope it's not 1)
But all options are bad.
AFAIK there will be some source generator support in F# in the future. But it's a different compiler, so I don't know whether it will ever work for C# and F# in a similar way.
Maybe you should ask the F# team about this.
But all options are bad.
AFAIK there will be some source generator support in F# in the future. But it's a different compiler, so I don't know whether it will ever work for C# and F# in a similar way.
Maybe you should ask the F# team about this.
Chet Husk@UrsEnzler @bradwilson @xunit if you're using source generators then you have some non-reflection-based API for defining tests - if you have that then it should be possible to make a combinator-based library that could emit those same primitives. That's the route I'd look down for F# here. Trying to chase Roslyn Analyzers is going to be pain otherwise IMO.
@bradwilson sorry - a library with a lot of small functions that you compose together to create the data structures in-memory. This is often pretty easy to do in F# because type inference makes defining the small functions very lightweight, and pervasive inlining makes is lower-cost.
@bradwilson The typical example here is a parser combinator library like FParsec or similar: https://fsharpforfunandprofit.com/posts/understanding-parser-combinators/
You make tiny functions that compose into the final product.