Xamarin.forms: [Enhancement] Make ExperimentalFlags class public

[domagojmedo]

Summary

By making ExperimentalFlags.cs public we can use ExperimentalFlags.IndicatorViewExperimental and others without needing magic strings.

One other side effect would be that when experimental flag is removed users would get errors because for example ExperimentalFlags.CarouselViewExperimental would not exist anymore but that would let them know that the feature is now ready, at the moment you need to check somewhere if flag can be removed or not.

VerifyFlagEnabled method can be moved to internal to keep it hidden

API Changes

public static class ExperimentalFlags // internal to public 
{
    public const string IndicatorViewExperimental = "IndicatorView_Experimental"; // internal to public
    ...
    internal static void VerifyFlagEnabled(...) // public to internal
}

Intended Use Case

Xamarin.Forms.Forms.SetFlags(ExperimentalFlags.IndicatorViewExperimental); on startup

[samhouts]

Interesting proposal. We explicitly made these "magic strings" so that there would be no build error when the feature was moved to stable. The check would simply be a no-op at that point.

[bmacombe]

Why not do both? Want to enable the feature and not have build errors when it's released...use the magic string. Want to enable the feature and get a build error...use the exposed const.

Let the dev pick the behavior.

So really the only change is to make the consts public

[bbenetskyy]

Also, I would like to add that it's quite a good idea and we should proceed with it 🤗. It will be much easier rather than copy/paste strings and after updates re-check all of them.

[dansiegel]

I think perhaps a better alternative for this would to provide some analyzers and IDE tooling that could rely on some additional metadata... maybe @pierceboggan could help with this...

1) Provide intellisense in Visual Studio / Visual Studio Mac for what flags exist in the installed version of Xamarin.Forms
2) Provide a Build Warning that could be configured to be an error if a Flag is set on the platform that is no longer a flag in an upgraded version...
3) Perhaps we could even make things smarter by adding an ExperimentalAttribute that would give the tooling teams the ability to hook in and analyze your workspace so if you use a control in your XAML we could generate some errors in the designer and possibly at build to make sure you know you need to go set a missing flag.

internal sealed class ExperimentalAttribute : Attribute
{
    public ExperimentalAttribute(string requiredFlag) { }
    public ExperimentalAttribute(string requiredFlag, params string[] onPlatforms) { }
}

[Experimental(ExperimentalFlags.SwipeViewExperimental)]
[ContentProperty("Content")]
[RenderWith(typeof(_SwipeViewRenderer))]
public class SwipeView : ContentView, IElementConfiguration<SwipeView>, ISwipeViewController
{
}

[Experimental(ExperimentalFlags.ShellUWPExperimental, Device.UWP)]
[ContentProperty(nameof(Items))]
public class Shell : Page, IShellController, IPropertyPropagationController
{
}

4) We could perhaps add a second attribute here as well to help light up similar functionality so that if you use something with a target head that references your project that isn't support we can alert you... For instance say you're using Shell with a macOS head we could get an alert that what you're doing won't be supported.