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
Use automatic type conversion to convert from () and T into T with Merge nodes #3776
This is an idea that will require some discussion to determine the feasibility and approach before implementation may begin.
When a Merge node receives only one input (either only the bottom input or only the left input), it can get stuck with some other random input type for the other, which doesn't match and results in a type error. This is only subtly visible because the two input connectors don't have the same color, but that is hard to spot.
Instead, we want the Merge node to receive the () type when it's not connected to anything, and use the automatic type conversion system to convert from () to T, for example () to List<Vector> if it needs to match with the other input of type List<Vector>.
I’ve been tracing this through the type inference system and it looks like the failure happens in TypingContext::infer, specifically in the valid_type function.
I see two possible approaches and wanted to confirm which direction is preferred:
Allow () to be compatible with any concrete type at the valid_type level (effectively treating () as a neutral / empty value).
Handle this during generic substitution instead (e.g., ignoring () when resolving generics).
Treat unconnected inputs specially earlier in inference rather than as Concrete(()).
@ShivangSingh68 thanks for your interest, but this is not open to beginner contributors. Please pay attention to the issue labels for which ones are Good First Issue. Also, ones labeled Graphene are explicitly not.
Activity
ShivangSingh68 commentedon Feb 19, 2026
I’ve been tracing this through the type inference system and it looks like the failure happens in TypingContext::infer, specifically in the valid_type function.
I see two possible approaches and wanted to confirm which direction is preferred:
Allow () to be compatible with any concrete type at the valid_type level (effectively treating () as a neutral / empty value).
Handle this during generic substitution instead (e.g., ignoring () when resolving generics).
Treat unconnected inputs specially earlier in inference rather than as Concrete(()).
Keavon commentedon Feb 19, 2026
@ShivangSingh68 thanks for your interest, but this is not open to beginner contributors. Please pay attention to the issue labels for which ones are Good First Issue. Also, ones labeled Graphene are explicitly not.