Having container types with i64 generates bad code when used in a service definition. Making the interface stricter prevents bad type assignments.
Also adds test case in user.thrift.
Recursive loose i64's could work but it requires changes across the renderer to use coerceType() and typeNodeForFieldType() differently. Both solutions could cause compatibility issues and I'm open to doing either.
Example:
The following thrift
service UserService {
i32 sum(1: list<i64> vals)
}
Would generate
export interface ISumArgsArgs {
vals: Array<number | Int64>;
}
export class SumArgs {
public vals: Array<Int64>;
constructor(args: ISumArgsArgs) {
if (args != null && args.vals != null) {
this.vals = args.vals;
}
else {
throw new thrift.Thrift.TProtocolException(thrift.Thrift.TProtocolExceptionType.UNKNOWN, "Required field[vals] is unset!");
}
}
// ...
}
The compiler would fail at this.vals = args.vals because of the type mismatch.
After these changes it will generate the following interface instead:
Having container types with
i64
generates bad code when used in a service definition. Making the interface stricter prevents bad type assignments.Also adds test case in
user.thrift
.Recursive loose
i64
's could work but it requires changes across the renderer to usecoerceType()
andtypeNodeForFieldType()
differently. Both solutions could cause compatibility issues and I'm open to doing either.Example:
The following thrift
Would generate
The compiler would fail at
this.vals = args.vals
because of the type mismatch.After these changes it will generate the following interface instead: