Re: GROOVY-12115/PR#2645 feedback request "@ClassTag - poor man's type reification"

On 7/26/26 14:03, Paul King wrote:
[...]
> So far so good. But there are two flavours:
>=20
> 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=20
selects two equal methods and should fail compilation. So the question=20
is that if you want this pass compilation, why is one method better than=
=20
the other. Without a solid answer to this it should fail compilation.=20
"it is exactly what we *sometimes* want" is not solid imho. My vote=20
would be for no preemption targets and compilation failure. Do we have=20
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=20
vote for compilation error. A failing program that with a change then is=
=20
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
> (=C3=A0 la Scala) could be a Groovy 7 conversation, but it's out of scop=
e
> here.

my main issue right now is that we introduce a concept from Scala, but=20
only partially and it got deprecated in Scala 3 as well. I did of course=
=20
not look at the new type system in Scala 3 all that much, so I cannot=20
really tell - but I wonder if we would here introduce something just to=20
deprecate it later.

bye Jochen