Proposal: FileIO.save keyword argument syntax (FileIO.kwsave ?)

[JonasIsensee]

I've added a new syntax to JLD2 and I'm wondering if this could be made compatible with FileIO.

Current example using FileIO:

x = 1
y = 2
z = 42
save("test.jld2", "x", x, "y", "zebra", z)
# or
save("test.jld2", Dict("x" => x, "y" => y, "zebra" => z))

This is clearly very verbose, particularly when variable names are long.
However, this could be made much cleaner if we use keyword argument syntax instead

using JLD2
jldsave("test.jld2"; x, y, zebra=z)

What's great about this, is that we use standard julia syntax and let the parser do the work of extracting
variable names. Until now this was only possible using the @save and @load macros from e.g. BSON, JLD, or JLD2
but these macros introduce odd (and limited) syntax and keep being misunderstood by newcomers.

I'm aware that kwarg stuff is typically not type-stable but this is rarely important when IO is involved.

The problem:
There already is a single-positional-argument method for FileIO.save that returns an anonymous function
to be used with pipes.

What do you think?
Is this interface idea useful enough to add it to FileIO in some way?

[johnnychen94]

I like this idea, I think we can deprecate the single-positional-argument method in favor of a manually written one data->save(f, data). But this takes time to proceed and I don't know how others feel about it.

In the meantime, adding a non-exported symbol kwsave seems okay to me. When the deprecation finishes, we can deprecate kwsave in favor of save.

[davidanthoff]

I think we can deprecate the single-positional-argument method

This is very heavily used in queryverse. The entire file IO story revolves around this pattern, so I would be very, very opposed to this :)

[timholy]

I recognize it's useful functionality, and we should keep it. But it's undocumented behavior of FileIO.save and it doesn't really fit with any Julia standard elsewhere (neither the "omit an IO object and fill in a default" nor the "first argument is a function which you can define via a do block"). I think we could call this something new, maybe writer, to hint that it returns a function that writes data? Or might savestreaming already solve that problem in a more conventional way?