Overall, I like this direction. It gives us a lightweight syntax with extensibility for future features, without feeling like it's abusing existing features (whether typealias
or macros).
With a very-general grammar for using
declarations, the proposal should say what happens for a parsed-but-unrecognized using
declaration. Is it always an error?
The syntax itself is general enough that I believe we'll be able to fit future features in there, but it would be nice to sketch out some of the more obvious ones so we're sure that we have something general enough that we won't regret it. The "Alternatives Considered" shows a few that aren't captured in the future directions, e.g., for warnings-as-errors control:
using treatAllWarnings(as: .error)
using treatWarning("DeprecatedDeclaration", as: .warning)
This does imply that the ordering of using
declarations can matter, which might not otherwise be the case.
Presumably, we also have, e.g.,
using upcomingFeature("InferIsolatedConformances")
using experimentalFeature("SomethingNewAndExciting")
although specific upcoming/experimental features would have to opt in to supporting this syntax, because it doesn't come "for free" and not all features can be made file-sensitive.
I do think the proposal should provide more justification on why it's important to have such a concise syntax for default actor isolation, where the "default actor isolation" part is effectively implied. The syntax I'm showing above is basically pulled from the package manifest, with the leading .
's removed, and implies that we could have this proposal use syntax like:
using defaultIsolation(MainActor)
// or
using defaultIsolation(nil)
If we went this route, the proposal could be simplified by removing the attribute and modifier grammar productions:
using-declaration -> using attribute
using-declaration -> using declaration-modifier
Doug