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

Reduce 'View.body' Visibility #385

Closed
filip-sakel opened this issue Mar 2, 2021 · 3 comments
Closed

Reduce 'View.body' Visibility #385

filip-sakel opened this issue Mar 2, 2021 · 3 comments

Comments

@filip-sakel
Copy link
Contributor

From its beginning, SwiftUI was able to make View.body inaccessible to users. Currently, if one opens the SwiftUI interface file, they won't find find body declarations for intrinsic SwiftUI Views, such as HStack or Text. This means that a user's typing Text().body actually yields the error: Value of type 'Text' has no member 'body'. This behavior of restricting all access to a property is unlike the leading-underscore rule, which hides underscore-prefixed declarations of Apple frameworks and the standard library from the autocomplete list — as is the cases for _ViewModifier_Content.

Unfortunately, I'm familiar with neither a Swift attribute that removes public protocol witnesses from the resulting interface, nor a way of enabling the leading-underscore rule for non-Apple frameworks. I recently came across a post on the Swift forums, however, that mentions the @_spi(...) attribute. This attribute is solely applicable to public or open declarations, which it hides from clients' autocompletion lists, resulting in a, behavior similar to that of the leading-underscore rule — albeit more limited.

I think it would be incredibly interesting to explore if the @spi attribute could be utilized by Tokamak's Never-body views — @_spi(TokamakCore) var body: Never { ... } — or if you have experimented with said attribute, I would be intrigued to learn about the limitations or roadblocks you've encountered.

Filip

@MaxDesiatov
Copy link
Collaborator

Thanks for creating this issue! I've stumbled upon @_spi before, but haven't been able to find any good information about it. Right now my focus is more on stability issues, but I'm happy to review a PR that properly utilizes these attributes to improve developer experience.

@filip-sakel
Copy link
Contributor Author

I've created a PR that tackles some of the most obvious cases: #386.

@filip-sakel
Copy link
Contributor Author

The PR was merged.

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

No branches or pull requests

2 participants