@warn_unqualified_access attribute name

Evolution Discussion
1

Hi everyone,

Following on from previous discussions around this topic (~1 week ago, ~7 years ago), I'm hoping we can reach a consensus as to how to improve the @warn_unqualified_access attribute. My original post was created with the intention of simply converting this attribute to camelCase, but this was reasonably pointed out that this attribute could do with a more holistic review in isolation.

This is one attribute from the early days of Swift that was never meant to be public, but has since been adopted lightly over the years (results on GitHub). Having never been through Evolution and a Swift 6 language mode in full development (offering the rare opportunity for a source-breaking change), it's a perfect time to evaluate this attribute.

As I see it, we have a few options:

  1. Update the name of the attribute to camelCase for consistency with other attributes (e.g. @warnUnqualifiedAccess) or improve the naming for improved left-to-right readability (e.g. @unqualifiedAccessWarning), optionally parameterizing to allow for future extensibility (e.g. @unqualifiedAccess(warning)).
  2. Demote this to a private attribute (@_warn_unqualified_access), and remove it from public documentation.
  3. Do nothing.

I personally think 1 seems like the most sensible direction for this attribute, introduced in a Swift 6 language mode. The attribute is lightly used but a useful feature to have for potentially ambiguous APIs. I'd also champion the spelling @unqualifiedAccess(warning) for the improved clarity and would easily allow for the obvious extension of @unqualifiedAccess(error).

2

All the uses I can see from the first two pages of that search seem to be forks of, modifications of, or didactic materials related to the Swift compiler, not 'adoption' as in a third-party API that makes use of it.

3

Try filtering the language to Swift - results.

There are a handful of projects using it, it seems.

4

Still mostly just test cases.

Deep in the search pages there are a few organic uses I can see, the purpose of which I'm not clear on as they're decorating APIs which almost certainly do not clash with top-level function names and, for that matter, decorate all or almost all APIs in the project. I suppose it could be some sort of attempt at forcing end users to always write self. when using their types, but I am not sure why we want or need to support that.

5

Apologies, that was not a good example. I've updated the link to remove a lot of compiler-fork-based results. Usage of the attribute appears to be very light indeed.

6

Well, I'm not sure how GitHub sorts these things, so the position of results in the list may not be relevant.

Also, it's worth keeping in mind that lots of Swift code (particularly for things like iOS applications) is not available on GitHub, so we can only glean so much from what we find there.

Personally, I think this attribute is useful, but in very, very niche situations. I think I've only ever used it once, years ago, and I can't even remember what for. I'm not surprised we don't find many instances of it in the wild, but I also don't see reason to remove it or "demote" it :man_shrugging:

3 Likes
7

I’ve run into a case where I wanted to use this but couldn’t.

struct S {
    // @warn_unqualified_access
    var type: Any.Type

    func foo(x: Any) {
        let dynamicType = type(of: x)
        // interpreted as self.type.init(of:) rather than Swift.type(of:). Compile error since no such init exists
    }
}

Since it only applies to methods and not properties, I couldn’t put the warning there.

1 Like
8

Here is one possible use case:

2 Likes