Calculator: Investigate migrating codebase to C#

[PaulDotNet]

Calculator is a great project for developers starting with UWP. However, it is implemented in C++ with managed extensions which I would consider rather a niche language with a niche features in a niche area of UI development. It is a niche within a niche within a niche.

I know C++ but would never consider this language for UI development. This ship has sailed around year 2000. On the other hand if Microsoft would pay me a huge salary to develop UI apps in C++ I would seriously consider it. Then I would say no.

Having calculator project in C# would make this project accessible to a much wider audience and maybe would help adoption of UWP somewhat.

Please consider converting this project to C#. Future generations would thank you for it.

[MicrosoftIssueBot]

This is your friendly Microsoft Issue Bot. I've seen this issue come in and have gone to tell a human about it.

[msftbot[bot]]

This pitch looks like it has everything it needs for review. In the meantime, we'll keep this idea open for discussion so the community has the chance to provide feedback. Check out our New Feedback Process for more info on the user-centered process we follow for new feature development.

[msftbot[bot]]

We reviewed the pitch and would love to explore this idea further! The pitch is a great start, but there are still some open questions. I am moving this issue into planning to iron out some of those details and I created calculator-specs/csharp to track progress. A human will follow up with some feedback on your pitch shortly. Keep in mind that not all ideas that make it into the planning phase are guaranteed to make it to release. For more information on next steps, check out our spec workflow.

[grochocki]

Thanks for the submission, @PaulDotNet! To be honest, this is something we had already been discussing internally, but it is great to see that there is community interest in this as well. While we agree that migrating the codebase to C# would offer lots of benefits, porting is no trivial task, so we'll want to consider the pros and cons and make sure we have a plan that minimizes disruptions to the project and the community. Moving to next stage to investigate some of these details and assigning to @rudyhuyn to help drive discussion.

[mdtauk]

I think because this project originated within the Windows OS code base, and probably relies on code from the previous Win32 code - this is why it is as it is.

The team maintaining the project would be well versed in C++ but it does make it more difficult for others wishing to contribute.

If the core C++ project had an ability to "plug-in" C# modules, then adding new features becomes easier. But then if you decide to go that way in refactoring, what are the Pros and Cons to moving everything to C#?

WinUI 3.0 also allows the breaking out of the sandbox. Does the project remain a UWP app? If C# WinUI 3.0 relies on using a .NET Core framework, does the app want to take a dependency on it?

That is without considering if there is merit to keeping core code in a cross platform compatible C language, with an option to build a MacOS or Linux UI fork, which the community could work on?

[Titaniumtown]

I would love to see the windows 10 calculator on linux, hope that becomes a thing in the near future.

[stevenbrix]

FWIW, the Uno platform ported the calculator to C# already:
https://github.com/unoplatform/calculator

/cc @rudyhuyn

[ghost]

I have a question in my mind: won't this impact the performance? C++ binaries are much faster and lightweight as compared to those created using C#.

This is really a concern as a calculator ought to be a handy application. We don't expect our users to wait for five seconds in order to see our splash screen.

[miloush]

@Rahul-Dixit the performance impact of switching from Win32 to UWP was already much higher than what I would deem acceptable for a calculator app. The managed libraries are compiled ahead-of-time to native code anyway, so I wouldn't expect much of a difference between C++ and C# here.