[Pitch] Custom Metadata Attributes

[Alejandro (Alejandro Alonso)]

@nnnnnnnn

The API for accessing attributes seems a little thin — are you planning to expand on what information we can access? It would be helpful to know things like the enclosing type of an instance property/method, the attributed symbol's name, etc. In addition, could we query in the other direction? Given a key path, could we query for a list of attributes?

Currently what's implemented is the type of the instance that this is on. I.e.

struct A {
  @CustomRuntimeAttribute
  var x: String
}

In this case I can actually provide you a value of (String.self, CustomRuntimeAttribute?), so the API could be edited to look like [(Any.Type, T?)] (or something wrapped in a struct with a proper name).

Yes, querying in the other direction is something a lot of folks have been asking for and I imagine we'll want to alter the implementation a bit to allow for efficient querying the other way. I would love if this interacted with the proposed API in the reflection pitch to allow for say Type.attributes or Field.attributes to get all the attributes on a specific type or a specific field.

@davedelong

When are these attachedTo: methods executed? If it's at load time, what are the potential impacts on process start-up time? If it's at first access, how do you handle a request to getAllInstances if a specific type hasn't been touched yet?

These attribute initializers are only called when you request them via the getAllInstances API. Also, only the specific attribute's initializers are called. For example, if you have 2 custom runtime attributes @A and @B and you ask for @B 's instances, we'll only initialize those attributes whose type is B and not any of the A ones.

@davedelong

Am I expected to implement this getAllInstances method myself? Am I implementing the attachedTo: methods myself? Or are these all synthesized by the compiler? If they're synthesized, how do I add type restrictions? If I implement them myself, how much responsibility do I have around concurrent access to attachedTo: vs getAllInstances, etc?

The getAllInstances method is provided for you via the proposed Reflection module ([Pitch] Reflection). You are expected to implement your own attachedTo: inits to constrain what type of declarations your attribute can be applied to.

@allevato

Does getAllInstances cache its result or scan all loaded images every time it's called? If we want to support dynamic libraries providing metadata-driven attributes, we probably need to do the latter.

So we do both. On platforms like Linux and Windows, we need to scan each section every time for every attribute. On platforms like Darwin, we can scan each section once, cache the results, and for new images loaded at runtime we'll be notified of new sections and only have to scan those and cache the results.

@allevato

Then, if I get fresh data every time getAllInstances is called, let's say the first call returns [A, B] and then a dylib is loaded later that adds C. Presumably a subsequent call to getAllInstances would return [A, B, C]. Do I need to do my own bookkeeping so that I only process C the next time around?

Yes, the API would return [A, B, C] and if you only wanted to consume C you'd need to do bookkeeping to figure what you've already seen.