Feature request: type annotations for CurrentAttributes attributes

[tavianator]

It would be nice to be able to write

class Current < ActiveSupport::CurrentAttributes
  #: Integer
  attribute :user_id
end

[KaanOzkan]

That will definitely be a nice feature to have more type safety. However, there are issues with this feature. First, that's not a valid RBS annotation as it's above a method call and Sorbet will complain, sorbet.run. So we'd need a different way of storing this information.

Second is how to extract this in runtime and associate it with the generated user_id methods. If it's a regular comment we'd have to parse the file, associate it to the attribute by looking at the line number. For large repos this overhead will be significant.

[tavianator]

Yeah fair. I don't know much about the internals but something similar already works for attr_accessor so I thought it could work similarly

[KaanOzkan]

attr_accessor actually has first class support in Sorbet, https://github.com/sorbet/sorbet/blob/master/rewriter/AttrReader.h. This rewriter works on the parse tree that contains the signature and the attr_accessor call and it converts it into static getter and setter methods with the appropriate signature. In this case since this is a Rails idiom and not a Ruby one we'd have to support it outside of Sorbet.

[bdewater-thatch]

We are also running into this. Would is be acceptable to add a keyword argument to attribute? The existing compiler would be augmented with an extension that intercepts tapioca_type to store the type given:

def attribute(*names, tapioca_type: "T.untyped", **kwargs)
  @__tapioca_current_attributes ||= {}
  names.each do |name|
    @__tapioca_current_attributes[name] = tapioca_type
  end

  super(*names, **kwargs)
end

There is undocumented prior art with objects that respond to __tapioca_type in the JsonApiClientResource and ActiveModelAttributes compilers, but that doesn't really fit here IMO.

[KaanOzkan]

Yeah I think that's acceptable cc @Morriar if you have any concerns