{Sync,}Settings as record classes

[YoshiRulz]

As demonstrated in https://github.com/TASEmulators/BizHawk/commit/eef190d332e3560cdb82f5713b1fcf8e54f97dc1. Essentially codegen for clone (though we're using MemberwiseClone for that) and equality methods (see also my old notes on equality codegen).

I'm fairly certain with is just semantic sugar for a ctor call, but I've put this in the 2.9 Milestone as a reminder to check it works under Mono. it does

[Morilli]

Record structs also seem very nice and clean to work with, although that would require bumping the project's language version to at least 10.0 (which I think is reasonable given that C# 10 is out for over a year now). Documentation: https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/proposals/csharp-10.0/record-structs

Example:

diff --git a/src/BizHawk.Emulation.Common/Database/FirmwareID.cs b/src/BizHawk.Emulation.Common/Database/FirmwareID.cs
index fb259f490..f06de4582 100644
--- a/src/BizHawk.Emulation.Common/Database/FirmwareID.cs
+++ b/src/BizHawk.Emulation.Common/Database/FirmwareID.cs
@@ -1,30 +1,11 @@
 namespace BizHawk.Emulation.Common
 {
-       public readonly struct FirmwareID
+       public readonly record struct FirmwareID(string System, string Firmware)
        {
-               public static bool operator ==(FirmwareID a, FirmwareID b) => a.Firmware == b.Firmware && a.System == b.System;
-
-               public static bool operator !=(FirmwareID a, FirmwareID b) => a.Firmware != b.Firmware || a.System != b.System;
-
                public string ConfigKey => $"{System}+{Firmware}";

-               public readonly string Firmware;
-
                public string MovieHeaderKey => $"{System}_Firmware_{Firmware}";

-               public readonly string System;
-
-               public FirmwareID(string system, string firmware)
-               {
-                       System = system;
-                       Firmware = firmware;
-               }
-
-               public override bool Equals(object obj) => obj is FirmwareID other
-                       && other.Firmware == Firmware && other.System == System;
-
-               public override int GetHashCode() => (System, Firmware).GetHashCode();
-
                public override string ToString() => ConfigKey;
        }
 }

[CasualPokePlayer]

C# 10 not being available to VS 2019 apparently is the reason we're at c# 9 for the main executable currently. Although I assume pulling the plug on VS 2019 would be vetoed by @zeromus for some time.

Although VS 2022 has been around for quite some time (and has matured quite a bit compared to its initial release), and most of the devs here use Rider anyways and don't deal with VS's bullshit. Cutting off VS 2019 support wouldn't really be that bad of a change.

[vadosnaprimer]

I think supporting the people who work on hawk on daily basis is important.

And we can't really say "okay vs2019 stays forever no matter what, deal with it", because we've evolved into switching to vs2019, and it's 4 years old now, so we'll have to move on eventually. I don't think barely active devs should just stall other people's progress until the former "feel" ready.

[YoshiRulz]

my notes on record struct

[zeromus]

"something out for a year" is a reason to wait five more years before using it, not beginning to use it today. "So I can refactor old code just for the hell of it" is no reason to do anything. Most of the devs around where use rider? Rider seems to work fine on windows 7. But the forms designer isn't working in bizhawk.

Reportedly vs2022 works fine on win7, but I'm not about to sacrifice my win7 workstation to find out. I'll need to image my drive first and then try it. Not really looking forward to that, but I know I have to do it at some point to buy myself a few more years on windows 7.

[vadosnaprimer]

I'm using vs2022 on 7 just fine.

[zeromus]

Yeah I know it works in theory but I can't chance slagging this workstation. Maybe I can install it with sandboxie...

[vadosnaprimer]

"something out for a year" is a reason to wait five more years before using it, not beginning to use it today.

Is that how you've written all your code so far?

"So I can refactor old code just for the hell of it" is no reason to do anything.

If the active team needs it, it's a fair reason.

I can't chance slagging this workstation

Has it happened to other win7 users trying vs2022?

[vadosnaprimer]

@zeromus is not responding to my questions, must be because he's fine with the change.