8000 Support configuring the access level of synthesized interfaces · Issue #7541 · tuist/tuist · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Support configuring the access level of synthesized interfaces #7541

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.

Sign up for GitHub

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

Jump to bottom
Closed
chrisjrex opened this issue Apr 30, 2025 · 4 comments · Fixed by #7550
Closed

Support configuring the access level of synthesized interfaces #7541

chrisjrex opened this issue Apr 30, 2025 · 4 comments · Fixed by #7550
Labels
size:S For issues that take an hour to implement

Comments

@chrisjrex
Copy link
Collaborator
chrisjrex commented Apr 30, 2025 •
edited
Loading

Why is this needed?

When using -enable-upcoming-feature InternalImportsByDefault, there is a compilation issue in the generated resource access code.

The enablement of the Swift feature AccessLevelOnImport causes compiling issues with synthesized interfaces defaulting to public.

This is because returned InternalImportsByDefault flag requires that if your API returns values from an imported framework on a public API interface, then you must make that import Public.

Build Error

Steps to address the need

  1. We should provide an interface where developers can configure the access level of those synthesized interfaces.

  2. (optional/nice to have) I think a good addition would also be to check the graph and if nothing depends on a project. then its accessors should default to internal
@pepicrft pepicrft added the size:S For issues that take an hour to implement label Apr 30, 2025
@pepicrft
Copy link
Contributor

Detecting the enablement of the flag at generation-time will be a bit tricky, since the flag can be defined in .xcconfig files, which can import other .xcconfig files and define values that are dynamically resolved at build-time.
Therefore, I'm inclined to expose an interface to declare the access level that should be used.

In the same way we have Project.options, we can have [Target.options] with an API along the lines of:

let target = Target(
  name: "MyApp", 
  options: .options(bundleAccessor: .bundleAccessor(accessLevel: .public)
)

That information can then be used at generation time to override this default. What do you think @tuist/community-core ?

@JoeSzymanskiNoom
Copy link

You might be able to simplify this by using the hasFeature check (https://www.swift.org/blog/using-upcoming-feature-flags/)

I think something like this might work for everyone:

#if hasFeature(InternalImportsByDefault)
public import Foundation
#else
import Foundation
#endif

@pepicrft
Copy link
Contributor
pepicrft commented May 1, 2025

Love the idea @JoeSzymanskiNoom! I was not aware of #if hasFeature(InternalImportsByDefault).

@chrisjrex chrisjrex mentioned this issue May 2, 2025
Merged
6 tasks
@chrisjrex
Copy link
Collaborator Author
chrisjrex commented May 2, 2025 •
edited
Loading

@pepicrft I implemented @JoeSzymanskiNoom's idea: #7550

Are you happy to close this issue with this fix? or would still like to explore the configuration option?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
size:S For issues that take an hour to implement
Projects
None yet
Milestone
No milestone
3 participants
@pepicrft @chrisjrex @JoeSzymanskiNoom
0