20134, "lydia-duncan", "IO module: proposed changes to iomode enum", "2022-06-30T22:34:49Z"
The iomode enum is used with all the open* standalone functions in the IO module to specify what kind of file to open.
The languages we looked at tend to use strings with similar values to these enum constants instead of defining an enum.
The IO subteam thinks we should rename the enum. At the very least it should be camelcased ioMode, but we could consider naming it something else like access (note: mode is the name used for the argument to the functions it is used in and that matches other languages).
We could also consider adding an overload for these functions with a param string argument instead of an argument of this enum type, or relying solely on that string argument. But we don't think it's a problem the way it is now.
The documentation for this enum also has a TODO for supporting four more modes:
- "a" - open the file for appending, creating if it does not already exist
- "ar" - open the file for appending and reading
- "cwx" - open the file for writing, throwing an error if the file already exists
- "cwrx" - open the file for reading and writing, throwing an error if the file already exists.
If we choose to add these after the other enum constants, it would not be a breaking change. However, if we felt it was better to add them interspersed among the already existing ones (seems unlikely), that would be a breaking change and we would want to do that before 2.0. It would also not be a breaking change if we had replaced the enum with strings and added them as string options.
The "x" in the last two new modes stands for "exclusive" and is useful for security purposes. There's a note on opentmp that it would maybe like to switch its default behavior to use one of them (TODO: link to opentmp issue when I make it)