(aws.String).ValueOrZero() etc.

[mitchellh]

Hello! We've discussed before whether the pointer wrappers are going to continue to exist or not, but in the case they do, I have another request.

Currently, in Terraform, we have to do this a LOT:

if awsGoObject.StringPointer == nil {
    d.Set("thing", "")
} else {
    d.Set("thing". *awsGoObject.StringPointer)
}

It would be very helpful if there was a function called ValueOrZero (the function name we usually use in situations like this). We could write one for every AWS type, but I feel this would be generally useful. The implementation would be something like this for every type:

func (ptr String) ValueOrZero() string {
    if ptr == nil {
        return ""
    }

    return *ptr
}

[lsegal]

Perhaps another strategy would be to have a configuration option to deserialize zero values as empty values so that strings and the like are never nil in responses. Would that work?

[mitchellh]

Yeah, for us that would work just as well.

For now I've worked around it with some reflection magic.

    // If the value is a pointer to a non-struct, get its value and
    // use that. This allows Set to take a pointer to primitives to
    // simplify the interface.
    reflectVal := reflect.ValueOf(value)
    if reflectVal.Kind() == reflect.Ptr {
        if reflectVal.IsNil() {
            // If the pointer is nil, then the value is just nil
            value = nil
        } else {
            // Otherwise, we dereference the pointer as long as its not
            // a pointer to a struct, since struct pointers are allowed.
            reflectVal = reflect.Indirect(reflectVal)
            if reflectVal.Kind() != reflect.Struct {
                value = reflectVal.Interface()
            }
        }
    }

[bmatsuo]

I'm partial to the initial suggestion from @mitchellh.

But, it's also the kind of function that is trivial for one to write themselves on an as needed basis. It's even possible for people to define them in an internal helper package if they want.

Is this a problem the package needs to solve?

[mitchellh]

@bmatsuo That's what we've done is implement it ourselves, but in two different projects we've needed it. If it is a common need, I believe it should be in the lib itself. It doesn't bother me anymore, we've solved it.

[LukeMauldin]

Yes, definitely need some solution to this issue