[Pitch] Rename public snake_case attributes to camelCase

Evolution Pitches
1

Hi everyone,

With increasing discussion and development effort concentrating around a Swift 6 language mode, this is one small inconsistency that I'd like to see corrected in time for Swift 6.

As of now this is unimplemented, but hopefully this can gauge an opinion behind this change (such as if this is even worth the time to implement). Thanks to the authors of SE-0383, as this pitch largely follows its structure.

Introduction

There is a language precedent for Swift's attributes to follow a camelCase naming convention, which is followed by all public attributes except for:

  • @requires_stored_property_inits
  • @warn_unqualified_access

I propose a renaming of these attributes to follow the existing camelCase naming convention:

  • @requiresStoredPropertyInits
  • @warnUnqualifiedAccess

Existing "prefixed" attributes (spelled with a leading underscore _) are considered non-public and are not in scope for this proposal.

Motivation

Naming consistency is a small but important part of writing Swift code. It affects everything: from learning Swift to writing Swift everyday. The more inconsistencies that arise the more complex the language becomes, even in small ways. While this change alone would arguably not be worthy of a source-breaking change, this becomes less of a blocking consideration as other source-breaking changes are already planned for a Swift 6 language mode.

The attributes in question (@requires_stored_property_inits and @warn_unqualified_access) were added in Swift 1.0 and Swift 2.0 respectively, before an apparent consensus arose around using camel case for attributes.

Detailed design

This would be a source-breaking change. To aid with migration to the renamed attributes, usage of the original property names should become a warning in Swift 5, and a hard error in Swift 6.

@warn_unqualified_access // warning: '@warn_unqualified_access' is deprecated in Swift 5 
                         // fixit: Change `@warn_unqualified_access` to `@warnUnqualifiedAccess` 
func myFunc() {}

@requires_stored_property_inits // warning: '@requires_stored_property_inits' is deprecated in Swift 5
                                // fixit: Change `@requires_stored_property_inits` to `@requiresStoredPropertyInits` 
class Requires { 
}

Once the fix-its are applied, this becomes:

@warnUnqualifiedAccess
func myFunc() {}

@requiresStoredPropertyInits
class Requires { 
}

This is a syntactic change only. The semantics of these attributes remain identical, so no further source changes are required.

Source compatibility

Continued usage of the existing names should compile under a pre-Swift 6 language mode. Under such language modes this proposal adds only an unconditional warning when the legacy names for these attributes are used, and provides diagnostics to avoid the warning by automatically migrating user code.

Effect on ABI stability

This proposal has no impact on ABI.

Effect on API resilience

None.

Alternatives Considered

Use this opportunity to rename the attributes in question, such as placing the noun before the verb to aid readability (and potentially parameterizing such attributes). Some ideas:

  • @unqualifiedAccessWarn
  • @unqualifiedAccess(warn)
  • @unqualifiedAccess(warning)
  • @storedPropertyInitsRequired
  • @storedPropertyInits(required)

However, this adds additional friction and complexity to what should be a very simple source migration. The pre-existing names are widely known and there's no additional motivation to change them.

31 Likes
2

+1 here, thank you for pushing on this inconsistency. This seems worthy of a source break in Swift 6 IMO.

3 Likes
3

My personal view on this is that if we’re going to be breaking source for these attributes, we should review their naming and behavior holistically. They pre-date Swift Evolution and have never been reviewed, and it is unlikely we would break source twice, so such consideration had better be had all at once.

I have never seen a use of @requires_stored_property_inits in the wild, so I wouldn’t characterize this as a “widely known” feature, and the use of “inits” to mean “default value” is entirely unprecedented.

If we are open to a source-breaking change, I would even be open to asking whether @requires_stored_property_inits holds its weight at all or should just be an underscored implementation detail for Obj-C bridging purposes.

26 Likes
4

My intention with this proposal was to make it so limited in scope and uncontroversial to essentially guarantee this could land in time for Swift 6. I haven't seen any major complaints or criticisms about these attributes as they exist today (other than the very light use of @requires_stored_property_inits as you mention) so the primary intention of this proposal was naming consistency.

Having said that, I agree with the notion that these attributes should be looked at and reviewed from scratch, given they've never been reviewed before (assuming any changes can be implemented in time for Swift 6). If this is the case, it's clear that both these attributes should reviewed separately given they are unrelated.

I'd love to hear anyone else's thoughts on ways these attributes could be improved, other than changing the names. This would be a good start for creating a couple of new proposals.

7 Likes