How to properly use Gtk.Connect?

[ravener]

So I just got [Gtk.Connect] working but I can't figure out how to satisfy the compiler that it's not null:

namespace MyApp
{
    public class TestWindow : Adw.ApplicationWindow
    {
        [Gtk.Connect] private readonly Gtk.Button _runButton;

        public TestWindow(Adw.Application app, Gtk.Builder builder) : base(builder.GetPointer("_root"), false)
        {
            Application = app;
            builder.Connect(this);
            _runButton.OnClicked += (sender, args) =>
            {
                Console.WriteLine("Hey!");
            };
        }

        public TestWindow(Adw.Application app) : this(app, new Gtk.Builder("window.ui"))
        {
        }
    }
}

Using _runButton triggers Dereference of a possibly null reference. (CS8602)

The code itself works fine, but the fact that the warning is there makes me feel like something is wrong and there must be a way to do it warning-free. Any advice? Is the only option to suppress compiler warnings?

[ravener]

Okay so I've searched through GitHub to see what others did, and they either do nothing or use #pragma warning disable or the ! operator.

I think I'll just use ! to suppress the warning. Still feels odd though, I guess I'm just too worried about 'best practices' that this feels unnatural, but I guess that's normal with GTK since it's a C library and bindings can sometimes be awkward.

[badcel]

It is currently a bit odd, I agree. As the fields are filled via reflection the flow analysis can't know about the initialization if you are using some *.ui files.

You could either not use *.ui files or initialize your member via [Gtk.Connect] private readonly Button button = default!; to have a none nullable field which gets initialized to value which is null, but not null for the compiler. As it is filed via reflection afterwards it should be fine as long as your *.ui file does not break.

The long term goal is to remove all the reflection code from the project which requires explicit initialization of the fields. This will probably happen via source generators to make life easier for the user. I would assume that such an implementation can / will use the MemberNotNull attribute which should potentially resolve the issue you mentioned.