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

101–110 of 110 posts

Re: Proposal: expression to create pointer to simple types

#101

Post by effdee »

anonacct38 wrote: post #83
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…

& doesn't always imply a value is on the heap. Escape analysis will ensure that pointers to the stack are safe. Here's an example with a bit of explanation: if you pass a value to fmt.Println it will escape. The raw println builtin does not cause values to escape. So calling the first function twice and seeing the same address for the value strongly implies stack allocation while calling the 2nd function twice and ge…

Minutes ago I was wondering about https://play.golang.org/p/9C0puRUstrP (via https://github.com/golang/go/issues/23440).

Thank you for explaining what's going on there! :)

And btw, compiling the above example with -gcflags="-m" (which I learned about earlier today) proves you right.

Re: Proposal: expression to create pointer to simple types

#102

Post by majewsky »

gher-shyu3i wrote: post #80
whateveracct wrote: post #56

I have so many BS helpers in my project to do this util.StrPtr("hello") util.BoolPtr(false) util.Int64Ptr(7) // etc This is just a gap in Go's design, so I'm glad this proposal exists :)

Generics would solve the issue.

Not entirely. Someone in the comments of the issue suggests to implement this with generics as:

  func PointerOf[T any](t T) *T {
    return &t
  }
But that has a nasty gotcha:

  func Process(x *int32) {
    if (x != nil) {
      fmt.Println(*x + 5);
    }
  }

  func main() {
    Process(nil);          //ok
    x := i32(5)
    Process(&x);           //ok
    Process(PointerOf(5)); //BOOM: cannot use PointerOf(5) (value of 
                           //type *int) as *int32 value in argument to Process
  }
Go's type coercion is quite primitive. It strictly works inside-out (propagating types strictly upwards in the AST), with the only exception that a numeric literal can be coerced into a specific numeric type by considering the immediate parent in the AST. So when you have `func f(x int32)` and you call it as `f(5)`, the literal 5 gets coerced into int32 to match the context it appears in. (The same strategy is also applied to determine the type of a nil literal.)

However, in `Process(PointerOf(5))`, the immediate surrounding of the literal 5 (the PointerOf call) does not coerce the literal into a specific type, so it takes on its default type, int.

The proposal (or, to be exact, both proposals) avoids this gotcha by requiring a type to be stated explicitly.

    Process(new(i32, 5));
    Process(&i32(5));

Re: Proposal: expression to create pointer to simple types

#103

Post by majewsky »

forgetfulness wrote: post #23
jerf wrote: post #14

Earlier quoted context omitted.

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…

Pointer-pointers are nice to implement linked data structures in C; they make a lot of logic surrounding re-seating the head pointer far simpler and with fewer edge cases.

This reminds me of the old adage that the level of experience of C developers can be ranked into 1 star, 2 stars, 3 stars and so on, based on the highest number of consecutive stars they use in type expressions.

Re: Proposal: expression to create pointer to simple types

#104

Post by majewsky »

uh_uh wrote: post #22

Why can't &3 work? Rob says 3 does not have a type and that's a problem. Would it be possible to change the Go compiler such that 3 has a type? (I'm guessing no, at least not easily, otherwise he'd be suggesting it, but I'm curious about the reason)

If the syntax were &3, you could use it to obtain a *int, but not a *int32, *uint64 or such.

Re: Proposal: expression to create pointer to simple types

#105

Post by bbatha »

majewsky wrote: post #102
gher-shyu3i wrote: post #80

Earlier quoted context omitted.

Generics would solve the issue.

Not entirely. Someone in the comments of the issue suggests to implement this with generics as: func PointerOf[T any](t T) *T { return &t } But that has a nasty gotcha: func Process(x *int32) { if (x != nil) { fmt.Println(*x + 5); } } func main() { Process(nil); //ok x := i32(5) Process(&x); //ok Process(PointerOf(5)); //BOOM: cannot use PointerOf(5) (value of //type *int) as *int32 value in argument to Process } Go'…

You can just write PointerOf(int32(5)) or PointerOf[int32](5). Or go could improve its type inference.

Re: Proposal: expression to create pointer to simple types

#107

Post by dang »

anon_tor_12345 wrote: post #79
cxr wrote: post #9

Earlier quoted context omitted.

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

are there hn hall monitors that I'm not aware of? like why are you policing people's jokes? For the life of me I will never understand why people voluntarily take on the mantle of authoritarian. Do you feel like you're contributing to something by censuring someone for a joke?

I get how it could come across that way, but cxr's comment is part of a long tradition of trying to avoid lame internet humor on HN. It's not because people don't like jokes - they just want to avoid the sort of jokes that grow like crabgrass and end up choking out more interesting discussion.

https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...

Re: Proposal: expression to create pointer to simple types

#108

Post by pjmlp »

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.

While true, generics are on the way to be released on the end of the year as first step.

Re: Proposal: expression to create pointer to simple types

#109

Post by anon_tor_12345 »

dang wrote: post #107
anon_tor_12345 wrote: post #79

Earlier quoted context omitted.

are there hn hall monitors that I'm not aware of? like why are you policing people's jokes? For the life of me I will never understand why people voluntarily take on the mantle of authoritarian. Do you feel like you're contributing to something by censuring someone for a joke?

I get how it could come across that way, but cxr's comment is part of a long tradition of trying to avoid lame internet humor on HN. It's not because people don't like jokes - they just want to avoid the sort of jokes that grow like crabgrass and end up choking out more interesting discussion. https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...

the archetypal censure of jokes grows like crabgrass just as much as jokes grow like crabgrass (because they're both low effort).

Re: Proposal: expression to create pointer to simple types

#110

Post by thomasahle »

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…

Russ Cox has some nice examples of the issues with this:

    Otherwise the meaning of &f().x is different for f() returning pointer-to-struct and f() returning struct.
    Similarly &m["x"] is a compile error today but would silently make a copy tomorrow rather than produce a pointer to the value in a map.
    All of that would be incredibly confusing and the source of many subtle bugs.
Post reply on HN