4 votes

Go proposal: expression to create pointer to simple types

Posted by unknown user
Tags: programming languages, go
https://github.com/golang/go/issues/45624

Link information

This data is scraped automatically and may be incorrect.

Authors
golang
Published
Apr 19 2021
Word count
35 words

6 comments

  1. [5]
    unknown user
    (edited )
    Link
    Apparently, Rob Pike was forced to work with some Go code generated for ProtoBuf 2, heh. Jokes aside, this is a utility that has been requested for a very long time, and I'm happy that it finally...

    Apparently, Rob Pike was forced to work with some Go code generated for ProtoBuf 2, heh.

    Jokes aside, this is a utility that has been requested for a very long time, and I'm happy that it finally has a decent (but not 100 %) chance of being added to the language.

    3 votes
    1. [2]
      jcdl
      Link Parent
      Ha. When I saw this on HN I hadn't noticed that it was Rob Pike proposing the change. That's convincing enough for me, and this change isn't super consequential in my view.

      Ha. When I saw this on HN I hadn't noticed that it was Rob Pike proposing the change. That's convincing enough for me, and this change isn't super consequential in my view.

      3 votes
      1. unknown user
        Link Parent
        I seriously recommend you to read the Go 2 Change Template that he filled at the end of the issue. Just one gem:

        I seriously recommend you to read the Go 2 Change Template that he filled at the end of the issue. Just one gem:

        Would you consider yourself a novice, intermediate, or experienced Go programmer?

        I have some experience.

        4 votes
    2. [2]
      skybrian
      Link Parent
      It didn’t seem convincing to me until you brought up protobufs. Other than that, I don’t see much call for having a mutable int all by itself. It’s really just to support a field being nil, and...

      It didn’t seem convincing to me until you brought up protobufs. Other than that, I don’t see much call for having a mutable int all by itself. It’s really just to support a field being nil, and that seems like an inelegant way to do it compared to having a proper union type, where it would be an extra bit to choose the variant.

      1 vote
      1. unknown user
        Link Parent
        I mean, you have just said it yourself: it's to support fields and values being nil or null. An example of a place where that is useful is JSON, especially when you work with APIs, standards, and...

        I mean, you have just said it yourself: it's to support fields and values being nil or null. An example of a place where that is useful is JSON, especially when you work with APIs, standards, and protocols in which {"a":null} and {} are two different values with different semantics, such as JSON Merge Patch.

        Would I like that to be supported through sum types instead? Yeah, and some post-generics proposals allow you to do that. But until then, I'll take pointers with a more comfy notation, heh.

        3 votes
  2. Moonchild
    (edited )
    Link
    Funny, c's supported this for 20 years now, with syntax like &(int){3}. But I guess c99 postdates plan9, so pike wouldn't have heard of it </snark> On a more serious note, I guess (don't know go)...

    Funny, c's supported this for 20 years now, with syntax like &(int){3}. But I guess c99 postdates plan9, so pike wouldn't have heard of it </snark>

    On a more serious note, I guess (don't know go) that this is analogous to clausecker's proposal?

    what's the problem with adding composite literals of simple types, like int{3}

    1 vote