Comment author: @lpw25

Attributes are not solely for the use of ppx. They flow through the compiler into ".cmt" and ".cmi" files. This can be useful for a variety of tools (e.g. documentation generators, code analyses). Warning on uninterpreted attributes would remove this important aspect of attributes.

You mention that it is difficult to check that all uses of a particular attribute have been found. However, it should be quite easy to provide support for this through the Ast_mapper interface. There are probably other things we could do to improve error checking of attributes, but since they are very extensible it is always going to be difficult. Where possible extension nodes should be used instead, as these will give an error if not interpreted by a ppx.

Comment author: @alainfrisch

As Leo said, attributes are not only intended for ppx mappers. Other uses include tools that parses .cmt/.cmti/.cmi files, tools which re-parse the source code, and the compiler itself (including some specific backends, and future versions of the compiler -- if we even introduce an "inline" attribute on function definitions, we don't want older versions of the compiler to complain on such attributes). Moreover, even ppx mappers don't necessarily want to remove attributes they understand: the same attributes could be used by other tools as well (e.g. a "default" attribute on a record field could be used to feed several "data-binding" code generators), and it can make sense to leave attributes so that they appear in .cmt/.cmti/.cmi files, e.g. for documentation generators (which count as "another tool").

So the proposal for a warning against attributes flowing to the compiler is overly restrictive.

That said, it could be interesting to formalize at least the supported locations (probably including some nesting information, how they interact with extension nodes, and maybe the form of supported payloads) for attributes, for each tool, using an ad hoc language. Such formal descriptions could be fed to a dedicated "type checker for attributes" tool (either a standalone tool or an identity ppx). This would support the use of attributes not only by ppx mappers, but also those tools which parse .cmt/.cmti/.cmi files, and those who re-parse the sources.

I can imagine that each tool would come with its description of supported attributes.

Those formal descriptions could also make it possible to detect automatically potential conflicts between attributes used by several tools in incompatible ways. They could also support IDEs and editor modes.

We probably need to wait to see more precisely how attributes will be used to design such as type system for attributes.
If such a nice system emerges, gets used widely by the community and is simple enough, it could even be integrated in the compiler directly (and probably executed before ppx mappers).

Anyway, I'm marking this issue as "won't fix", but I encourage everyone to contribute to a nice type system for attributes!

Comment author: @whitequark

Alain, you have very good points and I completely agree that your proposed solution is much better.