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
Interop Gen: Support Complex Literal Type ExpressionsΒ #465
Hi @nikeokoronkwo Iβd like to work on this issue.
My plan is to extend the interop_gen transformer to handle additional TypeScript literal type expressions, such as prefix unary literals (-1, +5) and simple constant expressions (1 + 2). Iβll build on the existing literal handling, keep the scope limited to constant cases, and generate equivalent Dart literals where itβs safe.
For anything that canβt be resolved safely, Iβll fall back to a conservative Dart type instead of failing. Iβll also add focused tests and make sure existing behavior stays unchanged.
Please let me know if this approach works β happy to adjust if needed.
I don't think it may need to be limited to constant cases only. I haven't looked much into this, but as long as the type checker can resolve it to a given type, then I think it checks out as a default. IIRC if it is just one literal type at the moment it resolves to its underlying type in Dart.
You can go ahead and get started and let me know how it looks!
Hey @nikeokoronkwo ,
I tested this on the current main branch and the existing literal_test passes (including unary numeric literals like -1 resolved via the type checker).
Is there a specific remaining case or scenario that is still not handled and that this issue is intended to track?
@Varadraj75 I donβt see a specific remaining case this issue is meant to track. More complex expressions such as binary or computed literals (1 + 2, 1 << 16) arenβt handled.
From testing on main, unary literal cases (e.g. -1) already work via the type checker and existing tests pass.
If this issue is meant to track support for computed/binary literal expressions (like 1 + 2, 1 << 16), could we clarify that explicitly? Otherwise, it seems the original scope may already be covered.
@nikeokoronkwo β please confirm whether this should remain open for computed literals or be closed and tracked separately.
Hey @nikeokoronkwo , I tested this on the current main branch and the existing literal_test passes (including unary numeric literals like -1 resolved via the type checker). Is there a specific remaining case or scenario that is still not handled and that this issue is intended to track?
The case for computed literals is not completed: not many changes were done concerning the addition of features to the generator in #503 and so it was more of a refactor.
Activity
sagar-h007 commentedon Jan 10, 2026
Hi @nikeokoronkwo Iβd like to work on this issue.
My plan is to extend the interop_gen transformer to handle additional TypeScript literal type expressions, such as prefix unary literals (-1, +5) and simple constant expressions (1 + 2). Iβll build on the existing literal handling, keep the scope limited to constant cases, and generate equivalent Dart literals where itβs safe.
For anything that canβt be resolved safely, Iβll fall back to a conservative Dart type instead of failing. Iβll also add focused tests and make sure existing behavior stays unchanged.
Please let me know if this approach works β happy to adjust if needed.
nikeokoronkwo commentedon Jan 11, 2026
Hey @sagar-h007. Thanks for your interest!
I don't think it may need to be limited to constant cases only. I haven't looked much into this, but as long as the type checker can resolve it to a given type, then I think it checks out as a default. IIRC if it is just one literal type at the moment it resolves to its underlying type in Dart.
You can go ahead and get started and let me know how it looks!
nikeokoronkwo commentedon Jan 17, 2026
This wasn't fixed yet in #503, so will reopen
Varadraj75 commentedon Feb 1, 2026
Hey @nikeokoronkwo ,
I tested this on the current main branch and the existing literal_test passes (including unary numeric literals like -1 resolved via the type checker).
Is there a specific remaining case or scenario that is still not handled and that this issue is intended to track?
sagar-h007 commentedon Feb 4, 2026
@Varadraj75 I donβt see a specific remaining case this issue is meant to track. More complex expressions such as binary or computed literals (1 + 2, 1 << 16) arenβt handled.
Varadraj75 commentedon Feb 5, 2026
Thanks for the clarification, @sagar-h007.
From testing on main, unary literal cases (e.g. -1) already work via the type checker and existing tests pass.
If this issue is meant to track support for computed/binary literal expressions (like 1 + 2, 1 << 16), could we clarify that explicitly? Otherwise, it seems the original scope may already be covered.
@nikeokoronkwo β please confirm whether this should remain open for computed literals or be closed and tracked separately.
nikeokoronkwo commentedon Feb 6, 2026
The case for computed literals is not completed: not many changes were done concerning the addition of features to the generator in #503 and so it was more of a refactor.
[-]Interop Gen: Support Additional Literal Types[/-][+]Interop Gen: Support Complex Literal Type Expressions[/+]