On 7/26/26 14:03, Paul King wrote:
[...]
So far so good. But there are two flavours:
1. New/opt-in overloads - uncontroversial, you're choosing the tagged
method explicitly.
2. *Preemption* - this handles the case where both a tagged method and
non-tagged method could both match. If we automatically preferred the
tagged method, this would be a silent behaviour change, but it is
exactly what we sometimes want. So, it's currently gated behind a
config allowlist: `CompilerConfiguration.classTagPreemptionTargets`,
defaulting to just `withDefault`.
if we are going by the book then essentially method selection here
selects two equal methods and should fail compilation. So the question
is that if you want this pass compilation, why is one method better than
the other. Without a solid answer to this it should fail compilation.
"it is exactly what we *sometimes* want" is not solid imho. My vote
would be for no preemption targets and compilation failure. Do we have
such cases in DGM?
[...]
My gut feel is leave as is, we can always add a system property or
dedicated commandline option later. And I think just "withDefault" to
start with. Anyone designing new APIs can just factor in ClassTag from
the start - it will only be where existing APIs exists and folks want
to retrofit the "reified" shorthand after the fact where more
allowlist items would be needed.
Well, if nothing int DGM requires a rethinking of this I would still
vote for compilation error. A failing program that with a change then is
compilable is not break of compatibility
One forward-looking note: `@ClassTag` deliberately only reifies the
erased `Class`, which is all today's `isInstance`-style consumers
need. A fuller "TypeTag" tier carrying the complete generic signature
(à la Scala) could be a Groovy 7 conversation, but it's out of scope
here.
my main issue right now is that we introduce a concept from Scala, but
only partially and it got deprecated in Scala 3 as well. I did of course
not look at the new type system in Scala 3 all that much, so I cannot
really tell - but I wonder if we would here introduce something just to
deprecate it later.
bye Jochen
