Cannot save empty named tuple using :bson format

[ablaom]

julia> JLSO.save("junk.jlso", :void=>NamedTuple(), format=:bson)

julia> JLSO.load("junk.jlso")
[warn | JLSO]: MethodError: no method matching NamedTuple{(),Tuple{}}()
Closest candidates are:
  NamedTuple{(),Tuple{}}(!Matched::T) where {names, T<:Tuple} at boot.jl:553
  NamedTuple{(),Tuple{}}(!Matched::Tuple) where {names, T<:Tuple} at namedtuple.jl:73
  NamedTuple{(),Tuple{}}(!Matched::Any) where {names, T<:Tuple} at namedtuple.jl:97
Dict{Symbol,Any} with 1 entry:
  :void => UInt8[0x1f, 0x8b, 0x08, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x13  … …

However, this works fine:

julia> using BSON
julia> bson("junk.bson", Dict(:x=>NamedTuple()))

julia> BSON.load("junk.bson")
Dict{Symbol,Any} with 1 entry:
  :x => NamedTuple()

And the default julia format works.

Looks like NamedTuple{(),Tuple{}}() is being called somewhere where NamedTuple{(),Tuple{}}(()) is wanted.

Sorry, but I do have a use case for saving empty named tuples 😄

julia> Pkg.installed()["BSON"]
v"0.2.5"

julia> Pkg.installed()["JLSO"]
v"2.1.0"

julia> versioninfo()
Julia Version 1.3.0
Commit 46ce4d7933 (2019-11-26 06:09 UTC)
Platform Info:
  OS: macOS (x86_64-apple-darwin19.0.0)
  CPU: Intel(R) Core(TM) i7-8850H CPU @ 2.60GHz
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-6.0.1 (ORCJIT, skylake)
Environment:
  JULIA_PATH = /Applications/Julia-1.3.app/Contents/Resources/julia/bin/julia
  JULIA_NUM_THREADS = 5

julia> Pkg.ins

[rofinn]

I don't think that's a fair comparison. Since the object serialization format is independent of the metadata, that would be more like:

julia> BSON.bson(bson("junk.bson", NamedTuple()))
ERROR: MethodError: no method matching bson(::String, ::NamedTuple{(),Tuple{}})
Closest candidates are:
  bson(::String; kws...) at /Users/rory/.julia/packages/BSON/XAts7/src/write.jl:85
  bson(::String, ::AbstractDict) at /Users/rory/.julia/packages/BSON/XAts7/src/write.jl:83
Stacktrace:
 [1] top-level scope at REPL[2]:1

I suppose we could special case BSON, but that would add extra complexity and prevent us from moving away from BSON for the header information if that was ever a requirement.

Perhaps the understanding is that the serialization applies to the entire dictionary/pairs rather than just the values? JLSO wasn't design that way because we want to have control over object names in order to aid in debugging failed deserializations or partial deserialization of the objects.