Move over current number when changing calculator modes

[p0358]

Problem Statement

The problem is that if a user switches calculator mode, they are always greeted with "0". Whatever number they had entered in other modes, for example programmer, won't carry over if they switch to for instance basic mode. It is a major bummer, because user needs to copy/remember the number each time.

Evidence or User Insights

I do a lot of calculations using Microsoft's Calculator. The most frequent use case is when I want to go from programmer mode into basic mode to do a non-integer division. Other times I do some simple calculations in basic mode, and would like to see what's the resultant number in hexadecimal system. The fact that the current number is cleared when switching operation mode is making my life much harder and program experience much less pleasant.

Proposal

Just carry over the current number when switching mode!
Basic mode calculations are always decimal, so if switching to programmer mode, move that number into decimal value, and vice-versa, if switching from programmer into basic, copy the decimal number there.
In case user doesn't need that number after switching the mode (what would be, in my opinion and experience, much more care), they could just press Esc on keyboard, or C in the UI, which is what they need to do anyways, if they wanted to clean the number without switching the mode.

Goals

User can save time and limit the hassle while working, and be more productive

Non-Goals

Low-Fidelity Concept

Example:

1. I'm in programmer mode and have this number. I want to divide it by 2, but get the full value, including what's after the comma
   

2. Let's switch to standard mode then
   

3. Oh, the number was reset? What was it...?
   

4. (now if I don't remember the number and go back into programmer mode, I would learn that the number was completely lost)

Requested Assignment

If possible, I would like to implement this.
I'm just suggesting this idea. I don't want to implement 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.

[grochocki]

Thanks for the detailed pitch, @p0358! This appears to be a duplicate of #114, which was already approved, pending figuring out some details around rounding. If you agree, I'd like to close this issue and continue the conversation in #114. Thoughts?

[p0358]

@grochocki Yes, it is fine. I haven't seen the other issue before creating this one. And I would love to see this implemented soon