Jeremy Kuhne

> Technically this isn't true, which was discovered after a bugfix was made It is true from the .NET Framework perspective. As you pointed out, even though it is technically...

I'm going to assert that using structs would be the best choice as it would improve encapsulation and "type safety". This came up again with #2218, where we really should...

Another valuable thing we could get out of "structifying" type definitions is that we could guard against sign extension problems with handles. See https://github.com/dotnet/winforms/issues/2004#issuecomment-538536982 and the bug fix with #2736....

Related issues/pulls: https://github.com/dotnet/runtime/pull/32091

Failed again: ``` TextBoxBase_Paste_InvokeNotEmpty_Success Assert.Equal() Failure\r\n ↓ (pos 1)\r\nExpected: abc\r\nActual: a\r\n ↑ (pos 1) at System.Windows.Forms.Tests.TextBoxBaseTests.TextBoxBase_Paste_InvokeNotEmpty_Success() in /_/src/System.Windows.Forms/tests/UnitTests/TextBoxBaseTests.cs:line 5957 ```

We do want/intend to move to function pointers for COM, it is just a matter of resource allocation. If folks are interested in contributing to make this happen we'd welcome...

> For me this is means that I should not worry about .NET 3.1 and can just change code. Yes, we only build the next version from our main branch....

@rickbrew I don't see any realistic way to do this without making these public (or making further risky changes). If you want to turn this into a formal proposal I'll...

@rickbrew the only real way to ensure that we keep compatibility is to make it officially public. That's our guarantee mechanism. That said, the likelihood of us changing this is...

@jeffhandley did we block `BinaryFormatter` in the runtime?