4 ms·

Been writing Go since 2012 and consider the status quo on all of these to be _features_. I may be in the minority there though

kbolino 2y ago
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?
- jen20 2y ago
  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 }
  - kbolino 2y ago
    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.
    - jen20 2y ago
      Indeed, I see no reason why taking the address of a literal couldn’t be added though, that’s a cheap win.
  - deergomoo 2y ago
    > 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.
    - jen20 2y ago
      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.
  - anothername12 2y ago
    lol We have this function implemented at least a dozen times through our mono repo. All named slightly different.
- isodude 2y ago
  Horrid, but this works. &([]bool{true}[0]) But at least it allows me to write it without declaring a variable first.
  - deleted 2y ago
    [deleted]
- postgressomethi 2y ago
  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.

kbolino 2y ago

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?

jen20 2y ago
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 }
- kbolino 2y ago
  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.
  - jen20 2y ago
    Indeed, I see no reason why taking the address of a literal couldn’t be added though, that’s a cheap win.
- deergomoo 2y ago
  > 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.
  - jen20 2y ago
    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.
- anothername12 2y ago
  lol We have this function implemented at least a dozen times through our mono repo. All named slightly different.
isodude 2y ago
Horrid, but this works. &([]bool{true}[0]) But at least it allows me to write it without declaring a variable first.
- deleted 2y ago
  [deleted]
postgressomethi 2y ago
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.