Go 1.26 new(expr) and the pointer problem I thought was solved

I saw the Go 1.26 release notes about new(expr) and immediately thought: great, I can delete all those generic ptr[T] helpers scattered through my codebase. Not quite.

The syntax works, but it gets weird with untyped constants in deeply nested AWS SDK structs. The compiler usually figures it out, but I hit snags where it complained about untyped string literals until I cast them explicitly. So I still need some helpers, just fewer of them.

If you've written Go for more than a week, you've hit the wall trying to get a pointer to a string literal. The AWS SDK and every database ORM want optional primitive pointers. You can't write &"us-east-1". The workarounds were: write a local ptr generic, import aws.String(), or do the v := "us-east-1"; p := &v dance that litters your code with single-use variables.

The stubborn compromise

Here's what bugs me. Why did we wait 15 years for new(42) when &42 is what everyone tries first? They could have made the ampersand work on literals. Instead we got a function call that feels like it's catering to parser edge cases, not humans.

I'll probably phase out my pointer utilities eventually. Not rushing into it though. I want to see how gofmt handles huge nested structs full of new() calls before I run a massive search-and-replace across everything.

If your code is full of aws.String() or custom ptr helpers, this upgrade is worth it.

FAQ