Microsoft-ui-xaml: Win32: GridLength doesn't match UWP GridLength

[dotMorten]

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:
```cs
    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]

The Win32/WinRT version looks a lot more feature-complete to me. What is the issue here? I like the new APIs and it's fully compatible with UWP from what I can see. I bet UWP is updated to support the new members... whenever they update UWP (if ever).

[dotMorten]

What is the issue here?

It's not about completion, but about consistency. You need completely different code to create a GridLength on the two platforms, because one is not even a subset of the other, not to mention the new one is immutable, and the old one isn't.

[robloo]

I just checked in a UWP C# app, the UWP version has the same signature as the Win32 version you mentioned above. Did you switch around the titles for the API examples?

Regardless, the constructors might be the same. Why are you setting Value and type directly instead of through a constructor? Also, if you are using C++ it seems GridLengthHelper is what you should be using.

https://docs.microsoft.com/en-us/uwp/api/windows.ui.xaml.gridlength?view=winrt-18362

If what I said above doesn't make any sense whatsoever, I bet it's a bug in the WinUI 3.0 preview and I'll shut up :)

[MikeHillberg]

Yes, there's a difference currently in the WinUI3 preview.

In WinUI _2_ (Xaml in Windows) GridLength has a constructor. In the current state of WinUI3 Preview, on the other hand, when using .Net Native (which is the version used for a UWP app), that constructor isn't present. That's because the .Net Native projection doesn't recognize GridLength in its new namespace (Microsoft instead of Windows). WinUI3 Preview in a Desktop app, however, uses .Net 5 and cs/winrt projection, which puts the constructor back on.

[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"

[dotMorten]

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.

[dotMorten]

Should WinUI aim to be a superset?

This is WinUI in both cases. It's just a matter of whether I'm compiling for UWP or Win32.

[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.