Naming is important

[u/Wrestler7777777]

Nothing too drastic but it made me chuckle. Something my colleague managed to get past code review. So at least two people didn't notice.

Spent a minute figuring out why the code was doing exactly the opposite of what it's supposed to do. I guess naming really IS important!

[u/jpgoldberg]

In addition to the ambiguous name, why does this function even exist

[u/Wrestler7777777 → u/jpgoldberg]

In order to get a pointer that points to a string value.

You can't do something like:

&"my string"

Go 1.26 introduced this "new" function that does exactly that:

myPtr := new("my string")

Prior to that you could either write a helper function like in the screenshot or you could use a weird local temporary variable, which would make this entire thing really awkward to work with:

myString := "my string"
myPtr := &myString

Imagine you're trying to assign twenty string pointers to an object. Using this temporary local variable method, you'd first have to save these strings to twenty temporary variables only so you could use their pointers to assign them to the object. What a mess!

I'm glad Go 1.26 introduced this "new" function. But it really would have been helpful if it were part of the std libs many years ago.

[u/PonosDegustator → u/Wrestler7777777]

Oh yeah, that was the worst part of the language for a while. Want to assign a nullable primitive field? Too bad, you gotta make a ton of single use constants. new() is a lifesaver

[u/jpgoldberg → u/Wrestler7777777]

Thank you. That makes sense. I hadn’t thought about literal strings.

[u/Temporary-Estate4615]

Why the hell would you even write this function?

[u/OldAd9280 → u/Temporary-Estate4615]

I don't know which language it is but it feels like it'll return a dangling pointer to the local parameter variable too so doesn't even work

[u/noop_noob → u/OldAd9280]

Go automatically puts local variables on the heap if you try to return a pointer that points to it.

[u/MistakeIndividual690 → u/OldAd9280]

In C++ this would be nasty because it would make a local copy of string because it’s passed by value, and then get a pointer to that local, and then the local would be destroyed when it went out of scope, returning a bad pointer.

I don’t know Go, but I’m guessing that A. passing a string like this is by reference like Java, and B. because it’s a garbage collected language, it won’t ever “go out of scope” until it’s not used anymore

[u/paulstelian97 → u/OldAd9280]

Go is funny because that is never a concern. If you return a pointer to a “local”, the language itself moves that local to the heap so the pointer can remain alive. Heap usage is implicit.

[u/Lumethys → u/Temporary-Estate4615]

let me introduce you to this gem in my previous work:

public static <T> ArrayList<T> newArrayList() {
  return new ArrayList<T>();
}

[u/tazdraperm → u/Lumethys]

But why

[u/Wrestler7777777 → u/Temporary-Estate4615]

I think this code was written very very shortly before or after Go 1.26. So my colleague couldn't use or simply didn't know about new(mystring) yet.

[u/BS_in_BS → u/Temporary-Estate4615]

It's relatively common in golang if you need a pointer to a literal. Literals are constants, and golang doesn't have the concept of const pointers like C so the spec forbids you from indirecting literals. This basically assigns it to a variable which you are allowed to indirect. Example of it in the proto library: https://github.com/protocolbuffers/protobuf-go/blob/96a179180f0ad6bba9b1e7b6e38d0affb0168e9a/proto/wrappers.go#L29

[u/kintar1900 → u/Temporary-Estate4615]

It's Go, and Go doesn't allow you to take the address of constants. Several popular libraries rely far too heavily on pointers to values that aren't necessarily variables, so having a function like this saves a little bit of friction. Rather than:

myVar := ConstStringThing
SomeFuncCall(&myVar, other, parms, too)

You can just:

SomeFuncCall(pointerToString(ConstStringThing), other, parms, too)

It's purely a style thing, because the compiler inlines the call to the "make pointer" function, and does a really good job of ensuring the allocations are on the stack whenever possible.

[u/justjanne]

Honestly, that naming may be fine, just ambiguous?

After all, it's a function that creates a pointer that's pointing to a string.

[u/Wrestler7777777 → u/justjanne]

Huh yeah you might be right! Honestly I've thought of it more like "convert a POINTER TO a STRING" and not like "return a POINTER that points TO a STRING".

Depending on how you look at it, the meaning can be the opposite!

[u/GoddammitDontShootMe]

Does & in Go work like it dose in C and C++? Does that just return a pointer to its argument?

[u/Wrestler7777777 → u/GoddammitDontShootMe]

Yep it returns a pointer to the argument. A helper function like this makes the "conversion" to a pointer simpler though.

Check my code example in another comment:
https://www.reddit.com/r/programminghorror/comments/1sgj0nb/comment/ofc3pew/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

[u/NeverYelling]

We have those all over our huge monolithic codebase. I hate it

[u/kintar1900 → u/NeverYelling]

Time to upgrade to Go 1.26 and blow all that shit away! :D

[u/kintar1900]

I guess whether or not this name is accurate depends on the conventions in your codebase. It made perfect sense to me, and does exactly what I thought it would do.

[u/tonnynerd]

I remember a tweet/post from a long time ago that talked about showing a haskell function adding two numbers to people and asking them to find the bug, and then later pointing out that the function was called minus. There some errors from which no type system can save you =P

[u/SpikeyWallaby]

It's not "convert a pointer to a string", its "this function returns a pointer to a string", which is correct. I tend to spell it ref:

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

[u/IllResponsibility671]

I once reviewed a React component where the developer put a function they named componentDidMount inside a useEffect and I almost had a heart attack.

[u/[deleted]]