@tgodzik @bjaglin i am having second thoughts about this. is my understanding even true? if origin is not a public field, does it really have to abide by any interface when quasiquotes are involved?

I think we use Origin in quite a few places outside of scalameta so it makes sense to move it out of internal.

Alternatively, we could expose more methods similar to pos like dialect and source, which would be much more useful for users.

(I see there is very active progress on this massive effort, thanks a lot for keeping backward compatibility in mind despite the complexity!)

@bjaglin thanks for chiming in. a further question:

• internal.Impl.unapply was problematic as that was the final result of this expansion;
• however, origin is "hidden" somewhere inside the tree and not directly exposed
  • after some thought, it looks to me no different from any other internal type, at least as far as it is used in the construction of a scalameta tree, so either all of them are bad or none are...
  • for instance, InternalTree is a base class of Tree, and yet it's underinternal package and hence outside of Mima
  • similarly, .syntax is implemented using TreeSyntax and that is also internal; so if you have code which uses this method, is it at risk if TreeSyntax changes?

I see your point, it's hard to tell what's really contractual at macro expansion time... Did you have a look at code generated by the quasiquotes macros with -Vprint:typer? I doubt that there is anything internal at the moment, but if there is, then I agree about your statement "either all of them are bad or none are".

... Did you have a look at code generated by the quasiquotes macros with -Vprint:typer?

i don't really know how to do that, truth be told... 😊

There is probably an easier way to do it, but what I did last time was to add -Vprint:typer to scalacOptions in a test module, run a full compile (ignoring the verbose output), touch a file exercising a macro by adding some dummy code, and check the output of that incremental compilation hunting for references.

And ... now that I write this, I realize javap -p -v on class files generated from macro-expanding sources is probably even easier to identify what really gets emitted and thus should be backward compatible. So that would be my recommendation!