You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
A constructor initialiser naming the base class only reaches the base constructor in C++ and JavaScript; Python, C#, Go, Rust and C treat it as a field #169
A MemberInitialiser named after the class's BaseType is the C++ : Base(args) idiom. C++ writes it into its initialiser list. JavaScript was fixed to honour it in #156 (for #103), in JavaScriptGenerator.WriteSuperCall. The other five generators treat it as an ordinary member named after the base:
Target
Output
Code
Python
self.Shape = 0. An explicit derived constructor never calls super().__init__(); only the synthesised one does
Shape: field sides, constructor Shape(int sides) with initialiser sides = sides.
Circle : Shape: field radius, constructor Circle(double radius) with initialisers Shape = 0 and radius = radius.
This is the JS DerivedClassFile fixture plus MemberInitialiser("Shape").
Results per target:
C++:: Shape(0), radius(radius), which is correct.
JavaScript:super(0);, which is correct.
Python: running the generated code, Circle(1.0).sides raises AttributeError: 'Circle' object has no attribute 'sides', because Shape.__init__ never ran.
Go:go vet reports cannot use 0 (untyped int constant) as Shape value in struct literal.
C#: CS1061, since there is no member Shape. Without : base(0) it also hits CS7036, since Shape has no parameterless constructor.
Rust: E0560, since there is no field Shape.
C: compile error, since there is no struct member Shape.
Why it matters
A derived class whose base needs constructor arguments can't be expressed portably in five of the seven targets. In Python the failure is silent until a base field is read. This is the same class of bug as #103, fixed there for JS only.
Suggested fix
Move the base-initialiser lookup out of JavaScriptGenerator.WriteSuperCall into StandardLanguageGenerator, and make it reachable from the C# generator too. The rule: an initialiser whose Name equals BaseType.Name.
Skip that initialiser when writing members, and emit the base call in each target's form:
Python:super().__init__(args) as the first statement of every derived constructor, with no arguments when there's no base initialiser.
C#:: base(args).
Go:Shape: NewShape(args).
Rust:base: Shape::new(args).
C:.base = Shape_create(args).
Acceptance criteria
The fixture above compiles or runs through the existing C, C++, Rust, Go and Python harnesses, and sides is set.
A Python test shows that a derived class with an explicit constructor and no base initialiser still runs the base __init__.
Related: #149 (the synthesised Python __init__ hides the base constructor when the derived class has no constructor of its own) and #103 (the JS-only version of this bug).
Priority: Medium. Five of seven targets mishandle a base-constructor initialiser. Four of them fail at compile time; Python fails silently at runtime, which is the worst case. It only arises for derived classes whose base takes constructor arguments.
Area:Coder/Languages: move base-initialiser detection from JavaScriptGenerator.WriteSuperCall into StandardLanguageGenerator, then apply it in the Python, C#, Go, Rust and C generators.
Activity
matt-edmondson commentedon Oct 6, 2026
Triage
Coder/Languages: move base-initialiser detection fromJavaScriptGenerator.WriteSuperCallintoStandardLanguageGenerator, then apply it in the Python, C#, Go, Rust and C generators.new Derived()throws ReferenceError #103, which was fixed for JS only in [patch] Call super() first in a JavaScript derived class's constructor #156. Related to Python: a subclass with no constructor gets a synthesised__init__(self)that hides its base class's constructor, soDerived(5)raises TypeError #149 (the synthesised Python__init__) and Generated C# is never compiled in tests and generated JavaScript is barely syntax-checked, so C# compile bugs slip through #162 (no C# compile test). No open PR covers it.__init__(self)that hides its base class's constructor, soDerived(5)raises TypeError #149, since both touch the Python constructor path. Pin the C# output text until Generated C# is never compiled in tests and generated JavaScript is barely syntax-checked, so C# compile bugs slip through #162 lands.Generated by Claude Code