You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Expected behavior: a compile-time error, telling you that this combination is invalid.
Actual behavior: a warning telling you that the result of == is unused.
The current behavior is that, in the absence of an override of == for <NSLayoutXAxisAnchor, NSLayoutYAxisAnchor>, it’s falling back to the global == → Equatable conformance for NSObject.
Ideally, we could write the appropriate overrides and mark them as @available(*, unavailable), but unfortunately, Swift is too clever for that. It realizes that there’s no point in choosing that implementation, so it again falls back to the NSObject version.
We can mark the methods as @available(*, deprecated, message: "It’s invalid to mix X and Y axes in this way") and then fatalError or -> Never (or both). But we still get a compile-time warning, not error.
One more sweeping workaround would be to stop using built-in UIKit anchors in favor of custom shorthand anchors, like .leading and .top instead of .leadingAnchor and .topAnchor. Those types can do whatever we want, which in this case would be to not inherit from NSObject, so then we would have more control over which operators are valid. It’s the nuclear option, but it might make layout expressions a little nicer to use.
As a stopgap, we should probably implement and deprecate the invalid combinations, just to improve error messaging.
The text was updated successfully, but these errors were encountered:
Expected behavior: a compile-time error, telling you that this combination is invalid.
Actual behavior: a warning telling you that the result of
==
is unused.The current behavior is that, in the absence of an override of
==
for<NSLayoutXAxisAnchor, NSLayoutYAxisAnchor>
, it’s falling back to the global==
→Equatable
conformance forNSObject
.Ideally, we could write the appropriate overrides and mark them as
@available(*, unavailable)
, but unfortunately, Swift is too clever for that. It realizes that there’s no point in choosing that implementation, so it again falls back to theNSObject
version.We can mark the methods as
@available(*, deprecated, message: "It’s invalid to mix X and Y axes in this way")
and thenfatalError
or-> Never
(or both). But we still get a compile-time warning, not error.One more sweeping workaround would be to stop using built-in UIKit anchors in favor of custom shorthand anchors, like
.leading
and.top
instead of.leadingAnchor
and.topAnchor
. Those types can do whatever we want, which in this case would be to not inherit fromNSObject
, so then we would have more control over which operators are valid. It’s the nuclear option, but it might make layout expressions a little nicer to use.As a stopgap, we should probably implement and deprecate the invalid combinations, just to improve error messaging.
The text was updated successfully, but these errors were encountered: