dotnet / dotnet/macios

Convenience init methods are exposed as regular constructors

Open
#23,761 4 comments 0 reactions 0 assignees View on GitHub
api-bindings enhancement roslyn-analyzer
Dominant language
C#
Stars
2.9k
Forks
576
Avg merge
2d 12h
Merged PRs (30d)
123

Description

### Apple platform

iOS, Mac Catalyst

### Framework version

net9.0-*

### Affected platform version

9.0.304

### Description

e.g. for `UIButton`

https://learn.microsoft.com/en-us/dotnet/api/uikit.uibutton.-ctor?view=xamarin-ios-sdk-12#uikit-uibutton-ctor(uikit-uibuttontype)

Although, it is documented behaviour, sub-classing `UIButton` will not behave as expected:
https://github.com/dotnet/maui/discussions/27185#discussioncomment-14313253

Obsoleting the constructor in favour of `UIButton.FromType` would promote the problem to being noticeable at compile time (especially since the log warning message does not appear to make it through to the debug console). And/or perhaps throwing an exception might be warranted since the behaviour is particularly confusing.

There are appear to be other similarly affected classes (e.g. `UIBarButtonItem`). In general, I would have expected convenience init functions to only be exposed as named constructors since only designated initializers can be used for subclassing on the native side.

### Steps to Reproduce

```C#
public class FocusableUIButton : UIButton
{
public FocusableUIButton()
: base()
{
// Can become focused
}

public FocusableUIButton(UIButtonType type)
: base(type)
{
// Cannot become focused since it maps to a convenience init
}

public override bool CanBecomeFocused => true;
}

```

### Did you find any workaround?

Use the default constructor.

### Relevant log output

_No response_

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.