#pragma strict_types int main (int argc, array(string) argv) { string s = argv[0]; Stdio.File ("test", "cw")->write (s); }
produces these warnings for the write call:
foo.pike:5: Warning: Type mismatch in argument 1 to write. foo.pike:5: Warning: Expected: array(string(0..255)) | string(0..255) | __attribute__("sprintf_format", string(0..255)). foo.pike:5: Warning: Got : string.
This is strictly speaking correct and in the long run it's probably a good idea to restrict I/O functions to octet strings. But in practice this warning is very cumbersome and will probably cause widespread proliferation of the fairly clumsy type "string(0..255)" if one tries to fix it. My view:
o There should be a better type name than "string(0..255)" for octet strings. (That type cannot be a typedef since typedef'ed types still don't work very well.)
o If we're to separate the types for octet and char strings, I think it should be done also when char strings happen to contain only narrow 8-bit chars. I.e. the string width is not really the important characteristic, rather it's whether the string contains characters or binary octets.
o Fixing the types for the I/O functions requires discussion (see e.g. points above). It ought to be done consistently over all I/O subsystems. Compat and utility functions might be required. This is not something to embark on at this time, I think.
To sum up, for 7.8 I think it's better to not introduce string(0..255) in write() etc. Opinions?