フォロー
C#やKotlinはコンパイラプラグインによるコード生成でメタプログラミングを解決するアプローチでソフトランディング?を図っている印象がある
@kekyo
おおここまでのものが…! 確かに言語を問わずに再利用性のあるコードジェネレーターを構築するのは難がありそうですね（まあトレンドではないのでしょうが）。
この辺はF# はF# のエコシステムで、と割り切るしか無さそう…。F# もリスペクトしつつVBとかは無視みたいなスタンスも取りづらいですし。
@atsushieno ですよね... VB さんは息してないのでアレですが :) VBがマクロをサポートしたら、ちょっと面白かったかも
.NET Core 1.0の時に複数言語で単一アセンブリをビルドできるように改良されていればSourceGeneratorも後ろ向きに受け入れたかも知れない、なんて事も考えるんですが （xprojが否認された時点で政治的に潰えたかもしれない
@kekyo
そうですね、政治的にMSBuildを刷新するのは無理だったんだろうなあ、って思います。あそこで下手を打つと.NET Coreの次世代としての.NET 5は出せなかっただろうし…
@atsushieno F#だとfscxというプロジェクトをやっていた事があります。残念ながらスタックしてしまいましたが...（遅々として進まなかった自分が悪かったと思ってる
今ならC#がSourceGeneratorをやったので受け入れられそうな気もしますが、F#でもSourceGeneratorに相当する何かを現在進行形で定義しようとしていたと思います。ただ、ジェネレーターのアプローチはC#ならC#、F#ならF#でコード生成してしまうので、MSBuildが言語毎にアセンブリをビルドしてしまうという問題を回避できないこと（滅茶苦茶頑張れば混ぜれるかもしれないけど、受け入れられなさそう）と、ジェネレータの実装がどうしても生々しくなるので万人向けじゃなくなるし保守が辛くなるという点でどうにも自分にはエレガントに感じられず、前向きになれそうにない...
言語組み込みのマクロはhaxeで少しかじった程度なんですが、それでもマクロ方式の方がベターだと思っています。
https://github.com/fscx-projects/fscx