About disallow unknown fields

[huihuimoe]

Hi, thank you for your outstanding work.

Regarding the disallow unknown fields in config under this commit c9ba810585243590329a44df2a7d24644f7c6ae1 , could you change it to just prompt a warn than throwing a fetal error when encountering an unknown field?

I usually write some notes in json using the unknown fields, like below, and now they are all unavailable.

{
    "interfaces": [
        {
            "Note1": "This is my wireguard server.",
            "name": "wg1",
            "proxyListen": "0.0.0.0:8444",
            "proxyMode": "zero-overhead",
            "proxyPSK": "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa=",
            "proxyFwmark": 0,
            "wgEndpoint": "127.0.0.1:8443",
            "wgFwmark": 0,
            "mtu": 1492,
            "batchMode": ""
        }
    ],
    "peers": [
        {
            "Note1": "This is my note.",
            "Note2": "This peer was peer to somewhere",
            "name": "name",
            "wgListen": "0.0.0.0:20222",
            "wgFwmark": 0,
            "proxyEndpoint": "1.1.1.1:4444",
            "proxyMode": "zero-overhead",
            "proxyPSK": "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa=",
            "proxyFwmark": 0,
            "mtu": 1492,
            "batchMode": ""
        }
    ]
}

Or is it possible to support a more human readable format like jsonc(json with comment) or toml?

[database64128]

could you change it to just prompt a warn than throwing a fetal error when encountering an unknown field?

https://github.com/golang/go/blob/e09bbaec69a8ff960110e13eabb3bef5331ecb0c/src/encoding/json/decode.go#L748

There isn't an exported error for this, so it can only be hacked around by checking the error string.

I usually write some notes in json using the unknown fields, like below, and now they are all unavailable.

As a workaround, you can put your notes in the name field.

Or is it possible to support a more human readable format like jsonc(json with comment) or toml?

None of these formats are supported by packages in the standard library, so adding support means more dependencies.

And I'm not quite convinced it's worth the effort to support additional config formats. The configuration of swgp-go should be fire-and-forget; it's not something you need to check often.