Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mark invalid combinations of anchors as deprecated #80

Open
ZevEisenberg opened this issue May 31, 2019 · 1 comment
Open

Mark invalid combinations of anchors as deprecated #80

ZevEisenberg opened this issue May 31, 2019 · 1 comment

Comments

@ZevEisenberg
Copy link
Collaborator

ZevEisenberg commented May 31, 2019

label.leadingAnchor == view.topAnchor

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.

@ZevEisenberg
Copy link
Collaborator Author

🤔 I wonder what effect this would have on compile time?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant