-3

In Go, suppose I have a []byte of UTF-8 that I want to return as a string.

func example() *string {
   byteArray := someFunction()
   text := string(byteArray)
   return &text
}

I would like to eliminate the text variable, but Go doesn't support the following:

func example() *string {
   byteArray := someFunction()
   return &string(byteArray)
}

Is this second example syntax correct? And if so, why doesn't Go support it?

jws
  • 2,171
  • 19
  • 30
  • 1
    is there a specific reason, why you want to handle pointers in this scenario? why dont you return string value in your function. and use the pointer syntax afterwards if you really need to pointer and not the value – meaningqo Sep 14 '21 at 12:29
  • Eliminating the pointer is a decent suggestion. If the function returns an error also, I think the pointer is helpful for error paths, e.g., `return nil, err` instead of `return "", err`. – jws Sep 14 '21 at 12:43
  • 1
    It was just a design-time decision by the language authors. [Note that you can write `return &T{1, "two"}`](https://play.golang.org/p/Tz1ZPhf31Q1), so why not `return &3`? But you can't do that. Why not? Because God, I mean Ken, said so. – torek Sep 14 '21 at 12:49
  • 1
    See https://stackoverflow.com/questions/15518919/take-address-of-value-inside-an-interface – JimB Sep 14 '21 at 12:55
  • @torek It feels right to me that & isn't allowed, but & not supported was unexpected. You gave another example I hadn't thought about, interesting! – jws Sep 14 '21 at 12:55
  • And also https://meta.stackoverflow.com/a/323382/32880 – JimB Sep 14 '21 at 13:04

2 Answers2

5

Because the spec defines is that way:

For an operand x of type T, the address operation &x generates a pointer of type *T to x. The operand must be addressable, that is, either a variable, pointer indirection, or slice indexing operation; or a field selector of an addressable struct operand; or an array indexing operation of an addressable array. As an exception to the addressability requirement, x may also be a (possibly parenthesized) composite literal.

Notice that type conversions (what you are trying to do with string(byteArray)) are not included in this list.

Marc
  • 19,394
  • 6
  • 47
  • 51
  • Thanks for the spec, but it is still unclear to me. I'd like to understand why `string(byteArray)` isn't addressable, and the motivation behind excluding the possibility. – jws Sep 14 '21 at 12:30
  • 3
    The quoted text gives you the full list of addressable operands. A type conversion is not one of them. As for the reason why, you would need to ask the Go authors. – Marc Sep 14 '21 at 12:31
  • 1
    @jws: "addressable" roughly means "has a location in memory", and the value is not stored in memory until you assign it to a variable. – JimB Sep 14 '21 at 12:40
  • @jws the community at large can't speak to the motivation of a specific few who possessed that motivation (the language authors). You would have to ask them. – Adrian Sep 14 '21 at 13:27
4

See Marc's answer for an official citation, but here's an intuitive reason for why Go doesn't support this.

Suppose the following code

var myString string
stringPointer := &myString
*stringPointer = "some new value"

Hopefully you know, this code will write some new value into myString. This is a basic use of pointers. Now consider the modified example (pretending that it is valid code):

var myBytes []byte
// modify myBytes...
stringPointer := &string(myString)
*stringPointer = "some new value"

The question is, where in the world (or computer) are we writing to?? Where is some new value going?

In order for the language to handle this correctly, the compiler would need some internal process to "promote" the temporary value to an invisible variable, and then take the address of that. This would be adding needless complexity to make some code slightly shorter, but create this confusing situation where we have pointers with no well defined location in the program. Instead of creating these confusing ghost-variables, the language delegates to the programmer to use their own variable as usual.

Hymns For Disco
  • 7,530
  • 2
  • 17
  • 33
  • 1
    Very good answer. The language could make implicit anonymous variables, but yes that's an ugly complication for a limited benefit. Thanks! – jws Sep 14 '21 at 13:22