[cfe-dev] Reflection/metaparsing implem

[David Blaikie via cfe-dev]

On Mon, Nov 11, 2019 at 2:08 PM David Rector <davrec at gmail.com> wrote:

>
>
> On Nov 11, 2019, at 4:09 PM, David Blaikie <dblaikie at gmail.com> wrote:
>
>
>
> On Mon, Nov 11, 2019 at 1:01 PM James Y Knight <jyknight at google.com>
> wrote:
>
>> On Mon, Nov 11, 2019 at 3:03 PM David Blaikie via cfe-dev <
>> cfe-dev at lists.llvm.org> wrote:
>>
>>> I think that'd still be a pretty hard sell - Clang's APIs and AST are
>>> volatile & intentionally so. People writing against the Clang APIs
>>> themselves with things like clang-tidy are aware of that. If we sold this
>>> as a feature to general C++ users, I don't think there would be a way to
>>> sufficiently communicate how volatile this will be - and end up backing
>>> ourselves into a corner & limiting the ability to change Clang.
>>>
>>
>> Does Clang's AST API _need_ to be unstable in order to keep up with
>> language changes, or is it just a convenience?
>>
>
> I imagine with sufficient heroics the AST could be maintained for a
> particular version - and /probably/ version-over-version (so the C++23 AST
> was backwards compatible with the C++20 AST, etc). In the same way that the
> language itself is mostly backwards compatible version over version.
>
>
>> Is this concern indicative of problems that a standardized AST API would
>> also have, or is unique to Clang's current API?
>>
>
> The concern is mostly indicative of a very high fidelity API - the lower
> level/more bare the API, the more brittle it'll be to changes (both
> refactoring improvements to Clang, and necessary changes to accommodate new
> language features). Standardizing something a little higher level could
> provide a lot more flexibility under the hood.
>
>
>
>
> Volatility issues could be managed. E.g. I’ve already implem’d so that
> CLANG_NO_REFLECT turns off reflection for any AST public const method or
> field — but note that it is a crutch; any public const method is either a)
> eventually going to be asked to be reflected or b) probably shouldn’t be a
> public const method.
>

Having something be "public" within Clang's codebase and users of Clang's
APIs that are explicitly documented as volatile is quite different from it
being public across significant amounts of end-user C++ code.

It makes a fair bit of sense for a lot of things to be public within the
former scope that aren't suitable to be public within the latter scope.

The goal is that people may ask for (a) but we may reasonably push back and
say that that level of fidelity maybe isn't worth the maintenance burden to
all C++ compilers indefinitely into the future.


>  (Reflection is an opportunity to look in the mirror — better to hit the
> gym than to design a funhouse mirror to fix the issue.)
>
> I imagine Other AST attributes — e.g. CLANG_REFLECT_DEPRECATED — could be
> defined so that the tool generates warnings and fixits whenever they are
> used.
>

Historically the C++ standard hasn't been terribly open to significant
deprecation/feature removal - it's probably not practical to plan on a
reflection API that would need that to maintain... maintainability.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20191111/9d0586b4/attachment.html>