Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Proposal: expression to create pointer to simple types

github.com

Post reply on HN
Print view View original

31–40 of 110 posts

Re: Proposal: expression to create pointer to simple types

#31

Post by fred256 »

gowld wrote: post #28
jerf wrote: post #16

Earlier quoted context omitted.

One of the things I think the Go tutorials don't make a big enough deal of is that Go is relatively explicit about allocations. := isn't just a shortcut for declaring variables, it's an allocation, and an error to use it when it doesn't allocate. var X Sometype isn't just a declaration, it's an allocation. := kinda smears the clarity by not allocating if you have a variable on the left that is already allocated, and…

I think the way to say it is that Go requires you to declare every allocation, but allows over-declaration in the case of copying. > := [...] an error to use it when it doesn't allocate. > := [...] not allocating if you have a variable on the left that is already allocated, This appears to be a contradiction. I suppose you mean something like "error to use it when there's no possible context where that line of code w…

a, b := 1, 2

If either a or b (but not both) were already defined, this won't re-define (and reallocate space for) them.

Re: Proposal: expression to create pointer to simple types

#32

Post by dang- »

cxr, I've been watching you for years, and you've got potential. You inspire me to be a better mod. If you're willing to take The Oath, you can be be part of the team enjoy the following benefits:

* Freedom to shitpost on as many alts as you like.

* Ever heard of a double upvote? Or a triple flag? Now you have.

* Monthly yoga and mindfulness with pg (you are not to make eye contact).

Fully understood if this is too great a responsibility, but you are truly one with the spirit of HN and its Guidelines.

Re: Proposal: expression to create pointer to simple types

#33

Post by masklinn »

jerf wrote: post #14
the-dude wrote: post #2

Can I create a pointer to a pointer?

Yes, however the utility of doing so in Go is fairly limited. Go has "pointers" but doesn't have pointer arithmetic, and the big use case of pointer-to-pointer in C is to iterate over an array of pointers via pointer arithmetic. Personally I would call them "references" since I consider pointer arithmetic to be the thing that makes pointers pointers and not just references, but that's a personal opinion, not a univer…

An other big use-case for pointers to pointers in C is pointer-type out parameters. Most of that use-case is handled by MRV, but I'm pretty sure there's the odd situation where a double pointer is either necessary or convenient (I remember seeing the odd one in Rust once in a while).

Re: Proposal: expression to create pointer to simple types

#34

Post by bigdubs »

It's interesting that this can be largely implemented oneself once type parameters are part of the language (as one thread commenter pointed out with `PointerOf(t T) *T`), I'm curious what other syntactical oddities become a thing of the past once we can create more expressive and typesafe functions for common kludges.

Re: Proposal: expression to create pointer to simple types

#35

Post by catlifeonmars »

jerf wrote: post #16
kevincox wrote: post #13

I was surprised that you can't apply & to any value. I thought it was gut an ordinary operator and it would ensure that the value it was applied to would be put onto the heap. s := S{} sp := &s // Works _ = sp _ = &S{} // Works i := int32(1) ip := &i // Works! _ = ip _ = &int32(1) // Doesn't work! https://play.golang.org/p/fdgvbEwJWgh It seems odd that you can't apply & to a function's return value. I think the best…

One of the things I think the Go tutorials don't make a big enough deal of is that Go is relatively explicit about allocations. := isn't just a shortcut for declaring variables, it's an allocation, and an error to use it when it doesn't allocate. var X Sometype isn't just a declaration, it's an allocation. := kinda smears the clarity by not allocating if you have a variable on the left that is already allocated, and…

I’m not sure I understood this correctly. Does the following allocate (on the heap)?

    foo := MyStruct{}

Re: Proposal: expression to create pointer to simple types

#36

Post by coldtea »

darksaints wrote: post #15

For a language that has taken extreme measures to exclude generics because they are deemed to complex, this proposal is absolutely surprising to me. And I'm still not sure what practical benefit comes from it.

Practical benefit in the sense of "you get a free pony" or "before you didn't have closures and now you do"? None.

Practical benefit in the sense of "you get to express something in a shorter, more uniform way"? Some.

Re: Proposal: expression to create pointer to simple types

#38

Post by tssva »

cxr wrote: post #9
Simplicitas wrote: post #6

Earlier quoted context omitted.

Is JavaScript a language?

Please don't use HN comments for posting low-quality jokes, even if (perhaps "especially if") they're considered acceptable/appropriate for other communities.

Can you point to some specific guidelines used to judge low-quality vs high-quality jokes for HN purposes? Or are we suppose to go by your personal and subjective opinion of low-quality vs high-quality comedy material?

Re: Proposal: expression to create pointer to simple types

#40

Post by gowld »

liendolucas wrote: post #24
kevincox wrote: post #13

I was surprised that you can't apply & to any value. I thought it was gut an ordinary operator and it would ensure that the value it was applied to would be put onto the heap. s := S{} sp := &s // Works _ = sp _ = &S{} // Works i := int32(1) ip := &i // Works! _ = ip _ = &int32(1) // Doesn't work! https://play.golang.org/p/fdgvbEwJWgh It seems odd that you can't apply & to a function's return value. I think the best…

>It seems odd that you can't apply & to a function's return value. Offtopic: Surprisingly I was asking myself this question but if possible in C... Is it?

Nope. You can only take a reference to an lvalue, which is (essentially) an expression that is legal to use in the form `my_lvalue = .... Otherwise, there's nothing to take the reference of.

    int* ref1() {   return &1; }
    
    -> error: lvalue required as unary '&' operand
   
    // 

    #include 
    int alloc()  {
      return *(int*)malloc(sizeof(int));
    }
    int* ref() {  return &alloc();  }

    ->  error: lvalue required as unary '&' operand
You can still be unsafe though, by making a reference to a stack-allocated object and letting it go out of scope :

    int* make_unsafe_ref() {  int a; return &a;  }
    ->  warning: function returns address of local variable
Post reply on HN