It is used as a branch based dependency in this example:

repositoryURL = "https://github.com/SDOSLabs/FLEX";
requirement = {
branch = feature/spm;
kind = branch;
};

I think that was supposed to be allowed?

This is what the proposal says:

> Products that contain a target which uses an unsafe flag will be ineligible to act as a dependency for other packages.

I would say "other packages" means any type of client here, so technically by the language in the proposal, this behaves correctly. Basically, unsafe flags can only be used by root packages.

Hmmm… assuming it technically behaves correctly, is requiring developers to wrap what should be a top-level package inside a "wrapper" package just so they can use a package with unsafe flags really the best experience here? Why would we not want some sort of mechanism built into Xcode to signify "yes, I really do want to use this package in my app"?

That said, I disagree on your interpretation—an app is not a swift package, so that copy is very misleading if this was intended :/

I'm probably missing out on the part of the discussion where this was fleshed out, but doesn't the idea of wrapping a package that has unsafe flags inside another package make it easier for someone to sneak unsafe flags into your app? (i.e. if I were to wrap FLEX in another package just so I could use it in my app while FLEX has unsafe flags)

I've just added another screenshot demonstrating that the "workaround" where you use the package with unsafe flags as a dependency of another package without unsafe flags does not work. Reflex has no unsafe flags and it depends on FLEX which has unsafe flags. Same error.

This basically means that packages with unsafe flags cannot be used at all in binary or app targets. Is this intentional?

I thought that as long as you were using local+branch packages you could get around it?

https://forums.swift.org/t/se-0238-package-manager-target-specific-build-settings/18341/10

I'm not 100% sure what the intent of the proposal was, the wording seems as if this was intended. However, I think this is overly restrictive and we should allow use of unsafe flags in local and branch-based dependencies.

Additionally, I think we have some confusion because for quite some time, the detection of unsafe flags was buggy, so there were a lot of cases which clearly should have been disallowed which were working nonetheless.

Cool, okay. Is there anything else I should do to get the ball rolling on this? Is a whole other proposal needed for example?

Are there any ways to force Xcode to accept unsafe flags? This is overly restrictive, our app uses Objective-C++ targets and need those unsafe flags.

Hi @NSExceptional, it's been a long time since you opened the issue, so we want to make sure the information provided is still relevant. Would you be able to clarify if this issue is reproducible for you on the command line with swift build or swift test?