New Issue: I/O module: should we change or deprecate %t for readf/writef?

Notifications Issues
1

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, read / readln / write / writeln are the only ones that work with the Encoder/Decoder. However, there is one exception. The readf / 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

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