example: suppose clang noticed that your project contains:

  • N multi-line preprocessor macros that all use control-flow constructs, and
  • M function templates that each take a function-object (which, in most/all calls to the template, is lambda whose lifetime is limited to the expression that contains the call to the template)...

...and emitted a text file containing statistics about these macros & lambdas that could then be attached to an issue thread & counted as a vote in favor of developing core-language support for macros that are evaluated/expanded during phase 7. (With this, you could write a macro that performs a syntax transformation like e.g. the one for range-for. Ideally, you'd have the ability to code the semantic rules as well.)

that might be fine if you're an implementor with an agenda to promote phase-7 macros, but what if you're a user who is interested in a completely different feature and a completely different code pattern that also occurs frequently and could be replaced with something better (if only that something-better were supported by the language), and you want to gather your own data about that—and maybe encourage other users to do the same? You'd want to give clang an option—say, "-freport-usage-stats-for-pattern=foo", where the pattern 'foo' is defined by a user-provided clang matcher plugin. Then users could attach these usage-report files to the relevant bug report thread.

later, if the feature is implemented, the pattern might be re-used by a 'tidy' tool that generates fixit replacements.

this post isn't really about clang or any of the languages that clang supports; i'm just wondering if this would be a helpful way for language designers to get a sense of how widely a feature would be used if it were implemented.


You must log in to comment.