-
Notifications
You must be signed in to change notification settings - Fork 565
Immutable/readonly structs (e.g. NSRange) #5110
Copy link
Copy link
Open
Labels
breaking-changeIf an issue or a pull request represents a breaking changeIf an issue or a pull request represents a breaking changeenhancementThe issue or pull request is an enhancementThe issue or pull request is an enhancementiOSIssues affecting iOSIssues affecting iOSmacOSIssues affecting macOSIssues affecting macOS
Milestone
Metadata
Metadata
Assignees
Labels
breaking-changeIf an issue or a pull request represents a breaking changeIf an issue or a pull request represents a breaking changeenhancementThe issue or pull request is an enhancementThe issue or pull request is an enhancementiOSIssues affecting iOSIssues affecting iOSmacOSIssues affecting macOSIssues affecting macOS
Type
Fields
Give feedbackNo fields configured for issues without a type.
This is not really a bug, but more of an open discussion about how some things are bound.
Take for example, NSRange: https://github.com/xamarin/xamarin-macios/blob/master/src/Foundation/NSRange.cs#L27
The struct is guidelines are for the struct to be immutable. (https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/struct)
Cocoa API doesn't seem to let it be mutated either: https://developer.apple.com/documentation/foundation/nsrange?language=objc
In case of structs, when a struct is in a readonly field/property or is passed as arguments to
inparameters, the compiler generates a defensive copy.This happens because
thisis mutable by default.C# 7.2 has some nice-ness that allows for structs to be marked as readonly, thus not allowing the
thisvariable to be set, but that requires the property to be fully readonly.Why was NSRange designed mutable? Might be the case for most structs bound