New Issue: I/O - should we prefer read(type t) to read(ref value)?

Notifications Issues
1

18496, "mppf", "I/O - should we prefer read(type t) to read(ref value)?", "2021-09-30T21:45:52Z"

Today, both of these read calls work:

var x = stdin.read(int);
var y: int;
stdin.read(y);

See IO — Chapel Documentation 1.25 (but note that you have to scroll down a bit to get to the type t version).

However, the read(y) example is using a read call that accepts the value to read in to by ref. But, in order to pass something by ref, it has to already exist. That seems unfortunate in the context of reading since we'd like to be able to construct the value in the process of reading. That comes up in particular when reading something that is not default-initializeable. Also note that the requirement that the value exists already makes it harder for the read implementation to allocate classes during the read or to resize an array during the read.

One downside to the read(type t) strategy is that the function either returns a value or throws. That is nice for making the initialization situation clear and intuitive, but we lose the chance for read to return a bool indicating if EOF has been reached. However there are two ways to address that issue:

  1. The code calling read(type t) can call a function to check to see if the channel is at EOF. This works just fine if the channel is only used by one task. The function one would need to call exists today but is undocumented. chapel/IO.chpl at d18e9ec571982887abe45ec3be43fd24b822e263 · chapel-lang/chapel · GitHub
  2. The code calling read(type t) can use try/catch to catch the EOFError in order to end a loop reading in data.

Due to the initialization issues mentioned above, the Encoder/Decoder design proposal uses a strategy of passing the type to decode in as an argument (rather than a ref to a value). Should we prefer the type t version of read more broadly?

We could consider:

  • deprecating the read(ref val) version entirely
  • updating the docs and primers to be more enthusiastic about the read(type t) version (where currently this version has a bit of a warning label on it in the docs).