null from optional types conflicts with null as addr_none in TS wrappers
#1198
Labels
discussion
Ideas that are not fully formed and require discussion
scope: ts-wrappers
TypeScript wrappers for Sandbox tests
Comments
Gusarich
added
discussion
|
As far as I understand, we have export type Maybe<T> = Just<T> | Nothing
export type Just<T> = [T]
export const Just = <T>(t: T): Just<T> => [t];
export const getJust = <T>(t: Just<T>): T => t[0];
export const isJust = <T>(t: Maybe<T>): t is Just<T> => Boolean(t);
export type Nothing = null
export const Nothing: Nothing = null;
export const isNothing = <T>(t: Maybe<T>): t is Nothing => !t;EDIT. Ha-ha, I wish it was that easy. |
5 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently, optional types are described as nullable ones (e.g.
boolean | null), which is fine for all types exceptAddress.@ton/corehandles addresses in such way thatnullmeansaddr_none, and it was implemented in Tact in a similar way due to the original developer being the same person who made the library.We want to rework addresses (#1119) for consistency and predictability, but
nulls prevent us from doing so without refactoring either the ton-core library itself or generated TS wrappers for Tact contracts. Current maintainer of the library suggested the second option.More precisely, we can make some type wrapper for
Maybethat will be used instead of the| nullthing to supportnullas a value itself. This will potentially resolve the problem and allow us to describeMaybe MsgAddresstype which will look likeMaybe<Address | ExternalAddress | null>.What do you think? @anton-trunov @verytactical
The text was updated successfully, but these errors were encountered: