fslang-suggestions VS ProjectReunion

Right, they have something like computation expressions, but they are not composable.

For your second point, I don't know if they could achieve that without type level programming. This is the Box of Pandora the designer of F# tried [0] not to open.

____

0. https://github.com/fsharp/fslang-suggestions/issues/243#issu...

That would be a breaking change; certainly it's impossible to do that in the presence of reflection, and I imagine there are simpler cases. (See discussion on the similar https://github.com/fsharp/fslang-suggestions/issues/884 .)

Trying to extend this https://github.com/fsharp/fslang-suggestions/issues/1089 to have two generics:

Basically, what I've made in Spiral. There is even a F# issue to improve the syntax.

Not currently supported but it's an open language suggestion that's likely to end up in F#. https://github.com/fsharp/fslang-suggestions/issues/506

Re: the argument accessor shorthand, there seems to be a proposal for exactly that (using _ instead of &): https://github.com/fsharp/fslang-suggestions/issues/506#issu...

I found this post (https://github.com/fsharp/fslang-suggestions/issues/975) which is about the same thing, but I'm confused as to what the final resolution was. There was mention of a taskSeq, but I can't find much info on that.

An issue in FSharp suggestions

F# doesn’t currently seem to support source generators.

You know, I'm not the only one surprised by this issue. If you take a look at the long threads around this issue, you can see many developers are complaining about the missing support for a very common feature such as authentication in Microsoft's own operating system!

> why Microsft has ceased anything beyond legacy support for it

That is not true at all. DirextX is COM, UWP was COM based, WinRT is still COM, WinUI and the Windows App SDK is again based on COM. C++, C#, Python and Rust are all supported programming languages for the Windows App SDK thanks to - you guessed it: COM. The C++, C# and Rust language projections for it are still being constantly updated: https://github.com/microsoft/xlang

When they started Project Reunion (code name for Windows APP SDK) back in 2021, just before Windows 11's release, they decided to double-down on COM. Like hard.

https://github.com/microsoft/WindowsAppSDK/blob/main/docs/fa...

> Practically speaking, any language & runtime that can handle COM objects can support Windows App SDK

The issue is described here: WebView2 does not support passing in a CoreWebView2Environment · Issue #1170 · microsoft/WindowsAppSDK (github.com)

.. and how many of the Microsoft applications actually use WinUI3? As far as I can tell they're doing their own thing (Office) or are Electron (Teams) or, at least in Windows 10, haven't actually been updated from WinForms.

The overhead of WinUI3 is pretty huge. The visual designer, a winning feature of Visual Studio for decades, is AWOL. Why? It's XAML, the same as the previous XAML designer! It's just .. broken?

The backward compatibility story is a disaster: you can get stuck in the UWP sandbox https://github.com/microsoft/WindowsAppSDK/issues/1780

What's the big Microsoft WinUI3 flagship app, then? Something people are actually using? Rather than just a few system dialogues. (How many Win11 settings pop up a Win32 dialogue box, still?)

Development for WinAppSdk and WinUI 3 is also very slow and Microsoft seems to not want to push it and invest more developers into it for some reason. They try to improve the framework, is just it's a small team. For example it was a headacke to apply the Mica backgrop and required unmanaged code, they made it simpler and reduced it to a line of code but it took months. I have 2 out of 7 issues fixed on WinAppSdk repository and 0 out of 8 issues fixed in the WinUI 3 repository (some of the older than a year). This are just my issues, there are many other opened by other developers. So yeah, it wasn't fun at all. PoweshellSDK had an issue with the Import-Module command and it wasn't fixed for more than a year and probably won't be ever fixed, but I'm glad I found a workaround, even more clean and more safe, otherwise I couldn't have added the posibility to uninstall and change Store apps.

As far as I know, there are still some issues with OIDC integration. See this, for example.