Alternate Mapping Strategy

[tooolbox]

First off, awesome project. Solves a problem that I and I'm sure many others have, is simple and elegant. Bravo!

I have in mind an alternate mapping strategy and I'm curious what you think:

1. Automatically map fields with identical names.
2. If there's a field in source with no match in dest, throw an error.
3. The tag sts:"-" can be used to tell the CLI to ignore a field.

Let's take this example:

type Source struct {
    A string
    B []byte
    Result int
}

type Dest struct {
    A string
    B string
    Total int
}

If you run the tool, you would get error: "Source.Result" has no destination in "Dest" or such. You could then add a tag:

type Source struct {
    // ...
    Result int `sts:"Total"`
}

The tool would then generate:

func Source2Dest(src examples.Source) dest.Dest {
	return dest.Dest{
		A:         src.A,
		B:         string(src.B),
		Total:        src.Result,
	}
}

This change of strategy would mean less verbosity in the "default" case (where you have two structs at different levels of your application with almost the same fields) while providing more safety (if you have a mismatch, the tool forces you to explicitly state what you want, i.e. tell it how to map or squelch the error with sts:"-").

[tooolbox]

Carrying this a step further, you would be able to have bi-directional safety. Take the following scenario:

type Source struct {
    A string
    B []byte
}

type Dest struct {
    A string
    B string
    Total int
}

When you run the tool, you would get error: "Dest.Total" has no reverse destination in "Source" or similar. Meaning, all the fields in Source map to Dest, but there are fields in Dest which do not know how to map back to Source. You would then need to change your code to:

type Source struct {
    A string
    B []byte
}

type Dest struct {
    A string
    B string
    Total int `sts:"-"`
}

[tooolbox]

Not a requirement, but a potential advancement if this stricter strategy is adopted:

sts could be set up as a VSCode plugin that automatically runs whenever you save files, and supplies linting if you add/rename/remove fields in Source or Dest such that sts can no longer convert between them.

Imagine, in the above example, that I rename Dest.A to Dest.G. VSCode could highlight both Source.A and Dest.G and warn me that sts: no matching field for conversion.

Again, this is sort of a separate issue but I wanted to highlight a potential application of sts if it had a strict mapping strategy.