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

51–60 of 110 posts

Re: Proposal: expression to create pointer to simple types

#51

Post by zeeboo »

kevincox wrote: post #43
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 don't see how: temp := someFunc() p := &temp is any less explicit than p := &someFunc() It seems that the `&` is still required to put something onto the heap.

What about `&m[x]` where m is some map? Does that heap allocate and create a copy, or is it a pointer to the actual storage slot? If the former, that's a hidden copy/allocation that didn't exist before, and if it's the latter, resizing the map invalidates the pointer, so it must be updated somehow.

Re: Proposal: expression to create pointer to simple types

#53

Post by marcosdumay »

vanderZwan wrote: post #8
w-m wrote: post #3

How exemplary that he filled in the full template questionnaire for language changes, including questions such as "Would you consider yourself a novice, intermediate, or experienced Go programmer?" (he replied "I have some experience").

> Is this about generics? > No. Not sure why, but something about this being the (first part of the) last question he had to answer makes it quite funny to me.

When you have two questions about a specific feature that every change proposal must answer, it's a sign that something needs improvement.

Re: Proposal: expression to create pointer to simple types

#54

Post by masklinn »

gowld wrote: post #40
liendolucas wrote: post #24

Earlier quoted context omitted.

>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…

> You can only take a reference to an lvalue, which is (essentially) an expression that is legal to use in the form `my_lvalue = ….

I mean it could implicitly allocate, that's what Rust does for instance.

Your second and third attempts would not compile though, the first would by returning a `&'static T`.

Re: Proposal: expression to create pointer to simple types

#55

Post by kevincox »

zeeboo wrote: post #51
kevincox wrote: post #43

Earlier quoted context omitted.

I don't see how: temp := someFunc() p := &temp is any less explicit than p := &someFunc() It seems that the `&` is still required to put something onto the heap.

What about `&m[x]` where m is some map? Does that heap allocate and create a copy, or is it a pointer to the actual storage slot? If the former, that's a hidden copy/allocation that didn't exist before, and if it's the latter, resizing the map invalidates the pointer, so it must be updated somehow.

`&` will "move" something to the heap if it isn't already on the heap.

The simpler way to think about it is that in Golang everything is on the heap. However the optimizer will move things to the stack if they don't have their address taken. I think the point about explicitness is that if you don't use `&` then it will be able to be put on the stack. So `&` doesn't cause a heap allocation but lack of `&` (or new()) confirms that there isn't one. (I don't actually know if that is true but I can't think of any counterexamples)

Re: Proposal: expression to create pointer to simple types

#57

Post by masklinn »

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)

> 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)

Why not? In fact it already kind-of does: Go has "default types" for most untyped constants. When you write

    i := 3
absent an explicit type, Go will fall back to "int".

Re: Proposal: expression to create pointer to simple types

#59

Post by coder543 »

kevincox wrote: post #44
catlifeonmars wrote: post #35

Earlier quoted context omitted.

I’m not sure I understood this correctly. Does the following allocate (on the heap)? foo := MyStruct{}

No. In this case foo will live on the stack (unless you take its address later). foo := MyStruct{} // Could live on the stack _ := &foo // Oh, now foo must live on the heap.

This isn't even true.

No matter what syntax you write inside a function, the Go compiler always has the final say on what is stack allocated and what is heap allocated. Taking the address of foo will not cause foo to be heap allocated unless Go is unable to prove that the pointer will live for less time than the current stack frame. Look up "escape analysis".

Basically the only way to guarantee that something will always be heap allocated is to assign it to a global variable. Even returning a pointer to that object from the current function is not a strong guarantee, since the compiler could inline this function into the caller and determine that everything can live happily inside the newly inlined stack frame without heap allocation.

Re: Proposal: expression to create pointer to simple types

#60

Post by coder543 »

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…

> it's an allocation

Most people probably think "heap allocation" when you say this. Go doesn't do dynamic allocations within a stack frame (alloca in C), so when you say "it's an allocation", what does that mean? It could be a stack allocation that occurred at compile time as a reservation in the size of the stack frame for that function. It could be a heap allocation. Only the compiler knows!

The Go compiler is the ultimate authority on what becomes a heap allocation. It tries to make everything into a stack allocation when possible, and stack allocations are "free".

Beyond that, a sufficiently smart compiler can reuse stack "allocations" within a single function as certain values become "dead" (never used again). So there isn't even guaranteed to be a 1:1 correspondence between "stack allocations" and variables that you declared inside the function.

So, I completely disagree with your statement about Go being "relatively explicit about allocations." It's one of the least explicit compiled languages in that regard.

Go makes a distinction between declaration and assignment, which is the syntax you're talking about. It really has nothing to do with allocations.

Post reply on HN