Pitch: Static Custom Attributes (Round #2)

[DevAndArtist (Adrian Meister)]

@hartbit

I'm not sure I understand. Static Custom Attributes can annotate more than just type declarations.

I meant that @staticAttribute itself goes on types (in your proposal it's restricted to a struct for now), not an actual type that can act as a static attribute.

One question about the restriction:

• Isn't @propertyDelegate already like @staticAttribute(/* with some predefined constraints */)?
  Property delegate types definitely will have ABI if they cross module boundary.

@hartbit

Static Custom Attributes don't have any ABI: they only exist at compile time.

How so? If you want your attributes be available across module boundary I'm pretty sure these will have ABI and if they would live in the stdlib they will be ABI locked. If in Swift 6 we had and static attribute @something as public struct something, which would have compiler support for its behavior and if this behavior needs a fix in Swift 7, then this fix won't be backwards compatible. (If I'm saying nonsense please feel free to correct me.)

I see it similarly to KeyPath's behavior. Right now if you call value[keyPath: ...] = newValue it will call the getter of value before it accesses the setter which is a bug (see this thread). If this bug is fixed in the next Swift release it will still remain on an OS that is ABI locked, which means that you never can just write value[keyPath: ...] = newValue if you targeting that OS where KeyPath has this bug. The compiler attributes should remain as compiler attributes and not become stdlib citizens.

@hartbit

Concerning the name casing, we have many attributes defined in the compiler which start with a lowercase letter. To keep source compatibility, we have to keep those with a lowercase name when transforming them into static custom attributes in the Standard Library. But all user-defined attributes MUST start with a upper-case letter.

I'm fine for user-attributes but why would we want to convert (some) compiler attributes to be like custom static attributes? This does not make sense to me. There are some attributes that are baked into the language because there was previously no other way and Apple frameworks required them, but these attributes are already written in upper camel case fashion (@IBOutlet). I think we should only move these attributes into their dedicated modules, but leave compiler attributes as they are now. I don't see any gain form @Swift.nonobjc other than breaking the rules custom attributes want to establish with this proposal.

Also one thing about IBOutlet as a custom attribute. You said that these won't have any ABI and would only exist at compile time. In that particular case I highly doubt that fact because I think @IBoutlet should be a property delegate which will be used as a baking storage for outlets and probably behave like DelayedMutable. This would not work if it was just annotated with @staticAttribute(declarations: [.variable], scopes: [.instance]).

@hartbit

I'm fairly sure there are no mistakes left. Which ones were you thinking about?

Sorry this was my mistake, I got distracted with the assumption that anything annotated with @Static* must have a static keyword applied, which is not true for nested types. No mistakes there.

---

Don't get me wrong, I like the overall direction, but I'm not convinced by the current state of the proposal.