Experimental features marked AvailableInProd

From Features.def...

#ifndef EXPERIMENTAL_FEATURE
// Warning: setting `AvailableInProd` to `true` on a feature means that the flag
//          cannot be dropped in the future.
#  define EXPERIMENTAL_FEATURE(FeatureName, AvailableInProd)  \
     LANGUAGE_FEATURE(FeatureName, 0, #FeatureName)
#endif

I'm looking for some clarification on a couple things around the AvailableInProd parameter with respect to feature flags.

Does 'production' specifically refer to the Xcode default toolchain, or is it a more general term that includes swift.org release toolchains?

Also, does the warning refer to just the flag itself, or does it also include the support for the feature? Are there any other resources around that provide more context on this?

Can you elaborate more on why you're asking? Having more context about why the answers to these questions matter to you will probably yield better help.

An experimental feature that is "available in production" can be enabled in the toolchain that ships with Xcode. I'm not sure about the status with respect to swift.org release toolchains but I believe the intention would be that they also be available in those toolchains as well. Basically, if an experimental feature is not available in production, then it can only be enabled with development toolchains and it is therefore reasonable to assume that no shipping Swift software depends on its functionality. The only dependencies you'd need to consider would be in the test suite.

It refers to the name of the feature flag. If the flag is available in production, then the flag may appear in shipping .swiftinterface files and it could therefore potentially break compatibility with existing SDKs to remove its name, even if removing the functionality would otherwise be ok. Whether or not it's ok to remove or change the functionality of an experimental feature really depends on the nature of the feature and how and where its used. By default, the expectation is that an experimental feature's functionality may change in incompatible ways from release to release, but for some experimental features that may not be practical. It all really depends on the feature.

Can you elaborate more on why you're asking?

We're interested in making the Differentiable Programming feature more widely available, for two reasons.

First, it would help to simplify our dev environment and stabilize our toolchain needs. We rely on the Differentiation module in some of our cross-platform projects. For now, we're limited to swift.org releases/nightlies. Our iOS app has an experimental feature that depends on it as well, which is more of a practical reason for asking.

Second, it would lower the barrier to entry when it comes to Differentiable Programming in Swift. It would help others experiment and adopt it in the future. Having the ability to enable it from the Xcode default toolchain in an iOS or macOS project would increase the potential audience. We'd love to share some of our wins (and struggles) using it, and it would be great to make it as easy as possible for people to try it out themselves.

1 Like