Pitch: Static Custom Attributes (Round #2)

[akyrtzi (Argyrios Kyrtzidis)]

@johnfairh

Right, you have to pull it out of the source using the bodyoffset and bodylength fields of the expr.argument thing. This is how call expressions are represented today - you can try it out using sourcekitd-test -req=structure (or grab SourceKitten and do sourcekitten structure ).

Unlike sourcekitd, SwiftSyntax has no limitations for providing the expression structure with full fidelity. But this only addresses a small part of the question on how to make use of these new attributes.

I'd like to offer some feedback to improve the proposal.

@hartbit

They exist only to be scanned using compiler tools like SwiftSyntax and SourceKit.

The proposal states this as the primary motivation for introducing the new attribute mechanism, and contrasts it with Sourcery templates, but it doesn't actually explain how they are going to be used by such tools and why they are a much better mechanism. Let's walk through some examples from a tool author's point of view that wants to take advantage of this mechanism:

@AutoCoding
class MyClass: NSObject {
// ...
}

Very simple case, we can just get the name here and infer any property we want to associate with it.

@Ignore(rule: .lineCount)
func b() {
// ...
}

We are now getting into interpreting expressions. This is still simple enough, we have the argument label name and it is a single dot-member expression that we can infer properties from its name.

@Ignore(rules: [.cyclomaticComplexity, .lineCount])
func a() {
// ...
}

Ok, not we are getting into needing to interpret array expressions. Let's explore the space a bit more, how about this:

@Ignore(rules: [.cyclomaticComplexity] + [.lineCount])
func a() {
// ...
}

At this point I think I'm going to hit the limit of what I can interpret. So let's say that there will be a tacit understanding between the users and tools to keep things simple in code. The above seems unreasonably complicated, but are there things that seem reasonable for users to want to write but are hitting similar limitations ? Say a user has this:

@Something(withValue: 42)
func a() {
// ...
}

@Something(withValue: 42)
func b() {
// ...
}

@Something(withValue: 42)
func c() {
// ...
}

Ok, as a tool author this is simple enough, I can see the argument label name and the integer value it accepts. But say the user wants to avoid hard-coding the values in each place:

let VALUE = 42 // this declaration can be in another file or module.

@Something(withValue: VALUE)
func a() {
// ...
}

@Something(withValue: VALUE)
func b() {
// ...
}

@Something(withValue: VALUE)
func c() {
// ...
}

Oops, my tool is unable to interpret this now.

These examples are intended to illustrate an issue that is not acknowledged in the proposal, which is that the currently hardcoded compiler attributes have constrained syntax grammar, not full expression generality, and their constrained syntax ensures they can be interpreted with a very simple syntactic processing.

Now, to clarify, I'm actually a fan of introducing custom attributes but I'd recommend that more thought should be given on how the feature, as proposed, affects and benefits tooling, particularly since tooling is stated as the primary motivation for the proposal.
Here's some food for thought, how is the @compileTimeAttribute feature relating to the compile-time interpreter ? What if we restrict the expressions to being evaluable at compile-time, what advantages and disadvantages would we get ?