Hacker News Reader

Comment by kbolino | Hacker News Reader

Being unable to access struct fields a.b.c without risking a panic sucks (and which caused the panic: a.b or b.c?). There's no remotely ergonomic solution to the problem, because there's no nil-safe struct member operator, there's no ternary operator, and if-statements can't be used as expressions.

This wouldn't be such a problem, since of course you can just "choose" to not use pointer- or interface-typed fields in "your" structs, but as soon as serialization, databases, or other people's APIs are involved, you don't have that "choice" anymore.

In the same vein, being unable to write e.g. &true or &"foo" is annoying too. If I can write &struct{...} why can't I write &true?

View on HN

Not being able to take a pointer to a literal is one of my pet peeves with Go - especially when using the AWS SDK, which requires pointers to literals everywhere. At least with generics, a wrapper function doesn't require a separate function per type though, and can be simply:

    package ptr

    func To[T any](v T) *T {
        return &v
    }

> especially when using the AWS SDK, which requires pointers to literals everywhere

On the plus side, at least the AWS SDK provides `aws.String()` and friends.

At least they did _something_, but it would be better if they moved into the modern age of Go and provided the version above as well.

lol We have this function implemented at least a dozen times through our mono repo. All named slightly different.

Yeah, that particular case got better with generics. It's still more verbose to write ptr.To(true) than &true though.

Unfortunately, there's no generic type constraint for "is an interface" or even "is nilable" so you can't use generics to solve nil-safety issues in general.

Indeed, I see no reason why taking the address of a literal couldn’t be added though, that’s a cheap win.

Horrid, but this works.

  &([]bool{true}[0])

But at least it allows me to write it without declaring a variable first.

I always thought there should be a two-arg overload of new, so you could write new(bool, true) or new(int, 20). Would solve the problem without any trickery.

Reply on news.ycombinator.com