Open CohenArthur opened 2 years ago
I think this might not be necessary for now, and I can't find a way of doing this without using reflection at runtime.
What we could maybe do is to actually parse the string during typechecking, resolve the type of each expression and then add code specific to primitives such as 15.format_int()
, format_float(5.4)
, value.field_that_is_a_bool.format_bool()
. For now, I think it's fine to expose those functions and have the user call them when trying to format primitive values, just like they would have to define their own "to string" functions for custom types.
We can do this by utilizing duck typing once we have proper type inference. By desugaring format strings to the following construct:
"this should expand to a number: {15} which is 15"
// to
"this should expand to a number: ".concat(format(15)).concat(" which is 15")
we can simply specialize format[int]()
, format[bool]()
and so on in the standard library. This also allows users to define their own formatting methods for their own types.
For these overloadable intrinsic functions, such as memory release/deinitialization, we need to add a lot of documentation and keep their number to a minimum
Results in a typechecking error due to calling concat with a string ("printing integer ") and an integer (15)