Why do I get "Composite Literal Uses Unkeyed" error?

Question

I'm relatively new to Go and am working on building out a request decoder. The request comes in JSON format and we decode that to a map[string]interface{}. We then pass that object data in to be decoded to our own ProcessRequest struct. As I said I'm new so I am reusing some logic in similar parts of the code wrote by previous developers. Essentially we are checking the map for the necessary pieces and then setting and returning those. Can someone explain to me why I am getting the titled error? Would I have to set the items all the way down to base structs that no longer have any nested? Is there a better way to accomplish what I want? Here is the code and the related structs. It is highlighting the error on the return of the model.ProcessRequest. TYIA

type ProcessRequest struct {
    RequestID string
    Message   *message.Message
    Rule      *Rule
    Options   *ProcessOptions
    //TODO: Context EvaluatorContext
    //TODO: Links
}

type Message struct {
    ID         int
    Key        string
    Source     string
    Headers    *HeaderSet
    Categories *CategorySet
    Properties *PropertySet
    Streams    *StreamSet
}

type RuleAction struct {
    Name       string
    Expression map[string]interface{}
}

type RuleLink struct {
    LinkID       int
    Condition    map[string]interface{}
    TargetRuleID int
}

type Rule struct {
    Name    string
    Code    string
    Actions []RuleAction
    Links   []RuleLink
}
type object = map[string]interface{}

func DecodeProcessRequest(dataObject map[string]interface{}) (*model.ProcessRequest, error) {
    var (
        requestID string
        message   *message.Message
        rule      *model.Rule
        options   *model.ProcessOptions
        err       error
    )

    if reqIDSrc, ok := dataObject["requestId"]; ok {
        if requestID, err = converter.ToString(reqIDSrc); err != nil {
            return nil, errors.Wrapf(err, "Error reading property 'requestID'")
        }
        if requestID == "" {
            return nil, errors.Errorf("Property 'requestID' is an empty string")
        }
    } else {
        return nil, errors.Errorf("Missing required property 'requestID'")
    }

    if messageSrc, ok := dataObject["message"]; ok {
        messageData, ok := messageSrc.(object)
        if !ok {
            return nil, errors.Errorf("Error reading property 'message': Value is not an object")
        }
        if message, err = DecodeMessage(messageData); err != nil {
            return nil, errors.Wrapf(err, "Error reading property 'message'")
        }
    } else {
        return nil, errors.Errorf("Missing required property 'message'")
    }

    if ruleSrc, ok := dataObject["rule"]; ok {
        ruleObj, ok := ruleSrc.(object)
        if !ok {
            return nil, errors.Errorf("Error reading property 'rule': Value is not an object")
        }
        if rule, err = DecodeRule(ruleObj); err != nil {
            return nil, errors.Wrapf(err, "Error reading 'rule' during decoding")
        }
    } else {
        return nil, errors.Errorf("Missing required property 'requestID'")
    }
    // Parse plain object to a Message struct
    return &model.ProcessRequest{
        requestID,
        message,
        rule,
        options,
    }, nil

}

Answer 1

super said in this comment:

In general, the warning says that you should prefer to use the syntax ProcessRequest{ RequestID: requestID, ... }. Naming the keys instead of unkeyed values.

That worked for me. Also the explanation by kostix in this comment really helped.

Basically the idea is that if you use "unkeyed" way of defining struct literals, the meaning of your definitions depends on the way the fields of the underlying type are layed out. Now consider that your type has three fields of type string in a certain order. Now a couple of iterations down the road some programmer moves the second field to the 1st position—your literal will still compile but will end up defining a completely different value at runtime.