Reconsider Raw pattern

[fricklerhandwerk]

We discussed in Nix team meeting on 2022-12-19, that there are multiple instances in the code which follow this pattern:

typedef std::variant<AllOutputs, OutputNames> _OutputsSpecRaw;

struct OutputsSpec : _OutputsSpecRaw {
    using Raw = _OutputsSpecRaw;
    using Raw::Raw;

    using Names = OutputNames;
    using All = AllOutputs;

    inline const Raw & raw() const {
        return static_cast<const Raw &>(*this);
    }

    inline Raw & raw() {
        return static_cast<Raw &>(*this);
    }

@edolstra asks whether we should do it that way, because it's quite verbose. Also adding aliases like in this case keeps both names around in the codebase.

@Ericson2314 do we have alternatives that are as convenient to use at the call site? Does there speak anything against having the variants as fields?

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/2022-12-19-nix-team-meeting-minutes-18/24121/1

[Ericson2314]

My thoughts on the raw pattern are basically:

1. Yes, the declaration is ugly and verbose, but it makes the code that uses the definition much nicer to read, and that is more important than the definition itself being nice to read.

2. When we someday rewrite in Rust this problem will go away, as Rust supports exactly this sort of code and data definition very nicely.

[Ericson2314]

My friend @jhartzell42 taught me about std::forward, which yields us a better version of this pattern!

The example in the issue would be rewritten:

struct OutputsSpec {
    struct Names { ... };

    struct All { ... };

    typedef std::variant<AllOutputs, OutputNames> Raw;

    Raw raw;

    /* The moral equivalent of `using Raw::Raw;` */
    OutputsSpec(auto &&... arg)
        : raw(std::forward<decltype(arg)>(arg)...)
    { }

Note how there are no more bad ...Raw names littering the top level!

I have given this new version a spin in c51d554; it is working well. I hope we can convert the other sum types in the codebase soon!

[Ericson2314]

@tfc By getting rid of inheritance, I hope this address your concerns from #6815 also!

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/2023-04-03-nix-team-meeting-minutes-46/27008/1