Win32: GridLength doesn't match UWP GridLength

Describe the bug Microsoft.UI.Xaml.GridLength is very different on Win32 vs UWP.

For instance Microsoft.UI.Xaml.GridLength has different constructors between UWP and .NET Core, and the .NET Core one is immutable. So I had to do this:

#if NETFX_CORE
        var size = new Microsoft.UI.Xaml.GridLength() { Value = 1, GridUnitType = Microsoft.UI.Xaml.GridUnitType.Star };
#elif NETCOREAPP
        var size = new Microsoft.UI.Xaml.GridLength(1, Microsoft.UI.Xaml.GridUnitType.Star);
#endif

Win32 version:

    public struct GridLength
    {
        public GridLength(double pixels);
        public GridLength(double value, GridUnitType type);

        public static GridLength Auto { get; }
        public double Value { get; }
        public GridUnitType GridUnitType { get; }
        public bool IsAbsolute { get; }
        public bool IsAuto { get; }
        public bool IsStar { get; }

        public override bool Equals(object oCompare);
        public bool Equals(GridLength gridLength);
        public override int GetHashCode();
        public override string ToString();

        public static bool operator ==(GridLength gl1, GridLength gl2);
        public static bool operator !=(GridLength gl1, GridLength gl2);
    }

UWP version:

    public struct GridLength
    {
        public double Value;
        public GridUnitType GridUnitType;
    }

Steps to reproduce the bug Inspect the Microsoft.UI.Xaml.GridLength type on both Win32 and UWP and notice the big differences.

Expected behavior Win32 looks like UWP version.

Version Info 3.0.0-preview1.200515.3

NuGet package version: 3.0.0-preview1.200515.3

Windows 10 version	Saw the problem?
Insider Build (xxxxx)
November 2019 Update (18363)	Yes
May 2019 Update (18362)
October 2018 Update (17763)
April 2018 Update (17134)
Fall Creators Update (16299)
Creators Update (15063)

Device form factor	Saw the problem?
Desktop	Yes
Mobile
Xbox
Surface Hub
IoT

Additional context

[robloo]

Regardless, the constructors might be the same. Why are you setting Value and type directly instead of through a constructor

No they are not. The UWP one doesn’t have a constructor. Also you’re comparing to Windows.UI.Xaml.GridLength, not Microsoft.UI.Xaml.GridLength on UWP. Those are not the same types.

It has been communicated since the beginning that Windows.UI.Xaml and Microsoft.UI.Xaml will be pretty much the same. I’m not confusing the two, I’m just using Windows.UI.Xaml to check what the API should be. This is just a bug in type projection (thanks @mikehillberg for checking) It’s not a change to the intended API’s.

[mdtauk]

If it comes to making choices between .NET / Win32 / UWP implementations of Xaml and other features. Should WinUI aim to be a superset?

Take pain points from one implementation and aim to fix them.

If good detailed documentation of every change is available, perhaps even with reasonings why a change is being made - how it benefits the platform. It would make the process of moving from a previous platform to WinUI Desktop a smoother process.

You would have thought .NET in it’s early days, was trying to provide new features, while “fixing” problems from Win32 GDI code.

Now would be the time to learn from .NET’s “mistakes”