Roman Chistokhodov

Maybe using signals? With variant-like argument which replaces the current *Param properties. This should allow to separate action from the passed data. I.e. arguments should not be stored (or at...

> LGTM. I wish we could reduce the boilerplate for handling the various filename arguments. You mean get rid of isConvertibleToString overloads? I think it can be done, but in...

> create would be even more inline with the existing names, but it might be too generic and could cause collisions. Well, read, write and append are quite generic too.

Btw we could also add something like writeToExisting to ensure that file exists. But then we will need to add appendToExisting too. That would be too many functions. Actually there...

> These use cases can be satisfied with File / File.reopen. It can't be expressed with stdio FILE. There's "r+" surely, but it opens for both reading and writing. And...

Of course user may address to fdopen and windowsHandleOpen if they want such fine control, but that means platform dependent code.

> Yep, I meant open the file for reading (to ensure it exists), then reopen it for write access. That's what I'm talking about. You will not be able to...

Regarding of crossplatform way to open files with flags that are not available in C stdio - I like the idea too. I guess by adding overload you mean the...

> Why do we need a new symbol for this? `append` is a separate symbol, so I added another separate symbol. And I did not want to touch `write` interface.

> Sure, we may never call it, but then what's the point of having an alternative UI that never gets drawn under an engine that doesn't support it? Mod-makers could...