Change argument order to read when reading a type

[yurivish]

Part of #20402.

This issue suggests making a change to the argument order of read to match the similar functionality in functions like parse.

Right now readstring is deprecated to read(filename, String), instead of read(String, filename).

reading a specific type feels analogous to parse(Int, str) and similar, so this issue suggests changing the argument order to match.

@StefanKarpinski gave some historical context for the current choice on Slack:

it was a pretty old choice, and the idea was that you do:

write(io, 0x12345678)
read(io, UInt32)

but we could change it because I agree that the ordering feels a bit weird and read(UInt32, io) might be better
so it would be this instead:

write(io, 0x12345678)
read(UInt32, io)

[StefanKarpinski]

Related: #19150, #25174.

[JeffBezanson]

-1. Having read and write use different argument orders seems confusing to me.

[StefanKarpinski]

Having read and parse use different argument orders is also confusing, however, and seem to be more confusing that I suspect having read and write with different orders would be.

[JeffBezanson]

read and write are naturally a pair though.

[StefanKarpinski]

Sure, and read and parse are naturally analogous. There's also an argument to be made that because read and write operate in opposite directions (input and output), having the opposite argument order makes sense. This is not as clear-cut as you're making it out to be.

[ararslan]

I think in the case of read, the oddest example is when the thing to read is a file path, so what you're actually passing is String then Type, which is indeed backwards from our typical argument order (#25174). However, when the first argument is an IO, the order is technically "conventional," though I admit that it feels kind of backwards to me anyway.

If you think about it like you're describing in prose the action being performed, read(io, T) is like saying, "read from io a T," which sounds considerably more Shakespearian than read(T, io): "read a T from io."

FWIW when readstring(x) became read(x, String), it was discussed in triage whether it should instead be read(String, x) and the triage decision was to follow the conventional argument order and put x first.

[Keno]

-1 from me as well. The biggest problem I have is that for read more generally, the arguments after the io describe what and how to read. E.g. we pass in a number n to read in n bytes from the I/O and packages that deal with endianness have a third argument for endianness. As a result it would seem weird to me to have the type go as the first argument, while other such descriptions would go after the io. Lastly I also think this is too late at this point.