It is possible to remove @experimental flag from scala.quoted.Quotes.CompilationInfoModule.XmacroSetting in next minor?

[rssh]

Are we have some policy, when @experimental API becomes stable?

Thinking about waiting for CompilationInfo.XmacroSettings (if it will be available in 3.2) or doing some custom code generation or visibility from sbt instead (if not) for configurable macro.

[bishabosha]

I think there is some discussion still to be had about the implementation of this feature - such as if it should be stable in tasty

[nicolasstucki]

Before we make this non-experimental we need to

• create a specification for this feature and probably a SIP
• we need to figure out how they should interact with transparent and non-transparent macros (related to recompilation)

[rssh]

Hmm, you mean that transparent and non-transparent macros invocations can be with different compiler options?
How can it be?
// I assume that changing compiler options cleans the project cache. If this is true - all should be ok.

[nicolasstucki]

The first issue I see is with non-transparent macros that might be recompiled from tasty files. This is not something we do often now but will become more useful un the future.

[rssh]

Can we describe a problematic use case? I still need help getting one.

Variants as I see now:

• compiler. Inlining is after pickling. So, during recompilation with different options - new options will be applied. But it is not a problem with the correct hashing. [Which, I guess, already implemented if we have not seen a catastrophe after changing -Xtarget flag]
• staging.
• • If we call macros defined in the library ad stored in Tasty, it will reevaluate in staging, but staging does not provide a way to set compiler options. [So, separate problem - setting compiler options in staging is impossible, but this is another issue]. From our side, all is still correct.
• • If we call from staging macros in the library, created by another macro that was compiled... and values in XmacroSetting during the compilation of 1-st macro will be other than during the second macro.
    Interesting question: where is the problem?
    I guess this is still correct until we have explicitly had some 'pure' deterministic macroses because now code in the macro can read JVM properties, configuration files, etc.

// In theory, it is possible to think about the 'environment' entity and support for storing the environment in Tasty in the future, but after the compiler will learn to check non-deterministic computations.

If the problematic issue is a tool that recompiles code with a new environment from tasty files
[aga - migration tool, maybe this is the problematic case], then any non-deterministic macro evaluation is impossible to support.

O'key, maybe we can warn about this in documentation as a tool limitation, but want our API to be deterministic?
Is this a such case?
(And possible solutions are

• A). Disallow this API in non-transient macroses
• B). Store environment and choose/(provide both?). options:
• • B.1). Macros is [Env, InExpr] => [OutExpr]. [ use-case: translation one macro into the other macro ]
• • B.2). Macros is [InExpr] => [OutExpr] and we should fix dependencies of Expr [ use=case: translating a code which is an application of macro in some tool, which is not a compiler itself]