19906, "mppf", "I/O module: should we change or deprecate %t for readf/writef?", "2022-05-31T12:52:51Z"
Spin-off from #19498.
In the Encoder/Decoder design, we are splitting the methods on channel/reader/writer in to methods that work with the Encoder/Decoder and methods that ignore it (see I/O module: relationship between Encoder/Decoder and channel · Issue #18504 · chapel-lang/chapel · GitHub ). For the most part,
writeln are the only ones that work with the Encoder/Decoder. However, there is one exception. The
writef calls generally ignore the Encoder/Decoder but when using the
%t format string they will work through the Encoder/Decoder. This makes it an outlier and an exception to the more general rule about which methods work with the Encoder/Decoder.
%t is also an odd thing in format strings because it's not really clear how precision or length should work with it. Say you are printing a record with a few float fields, what should "%3.1t" mean? Should it be controlling the total object or adjusting the formatting of each field within it? We have this problem also for complex numbers -- see #18498.
What should we do about this? Some possibilities:
A. Do nothing - %t is OK the way it is.
- idea here would be that the exception is understandable because it is the purpose of %t to behave as if calling read/write
- still have to make a decision about what field width / precision mean in this context
B. Change %t to only apply to builtin types
- "You know what this argument's type is, so please just print it out the default way rather than making me tell you its type." ( I/O module: adjustments to read methods · Issue #19498 · chapel-lang/chapel · GitHub )
- Note that we already have %n for any numeric type. %t would also include bytes and string.
C. Replace %t with %? which only applies to builtin types.
- %? is unused so far in format strings and might be more intuitive
D. Deprecate %t without replacement
- expecting that people can just write separate read/write calls in addition to readf/writef