28470, "DanilaFe", "[Bug]: cannot create records with management-generic fields", "2026-02-27T21:13:50Z"
We support management-generic type fields in classes. https://github.com/Cray/chapel-private/issues/7701 contains an example, as does types/type_variables/nelson/dependentTypeOverClasses, which was requested pre-Git, but made work somewhere between Move PRIM_NEW handling to resolution by mppf · Pull Request #3728 · chapel-lang/chapel · GitHub and Remove more where clauses by mppf · Pull Request #10256 · chapel-lang/chapel · GitHub.
However, it seems like trying this same pattern with records results in a strange error.
class A {
proc hello() { writeln("hello from A!"); }
}
record N {
type X;
var x = new owned X();
}
proc main() {
var n = new N(X=A);
n.x.hello();
}
$CHPL_HOME/modules/internal/ChapelBase.chpl:2531: error: could not find a copy initializer ('init=') for type 'N(anymanaged A)' from type 'N(anymanaged A)'
tmpdebug.chpl:5: note: this candidate did not match: init=(this: N(anymanaged A), other: N(anymanaged A)) [2346777]
$CHPL_HOME/modules/internal/ChapelBase.chpl:2531: note: because method call receiver with type 'N(anymanaged A)'
tmpdebug.chpl:5: note: is passed to formal 'ref this: N(anymanaged A) [2346781]'
$CHPL_HOME/modules/internal/ChapelBase.chpl:2531: note: unresolved call had id 2347554
I investigated this briefly. There are two pieces:
- For a reason I'm not sure about, we generate and resolve an
init=signature even if there's no copy-initialization in the program. - Even though the formal and actual types look the same (
N(anymanaged A)) they have differing compiler-generated IDs, so they either differ or some part of our instantiation-deduplication logic went wrong.
This is relates to other concerns about this language feature (anymanaged / generic type fields), since it works very inconsistently today even for classes. I have an IOU to open a design issue for this.