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

91–100 of 110 posts

Re: Proposal: expression to create pointer to simple types

#91

Post by Laremere »

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)

I asked that in the thread, response here: https://github.com/golang/go/issues/45624#issuecomment-82259... With my reply (and further exploration) here: https://github.com/golang/go/issues/45624#issuecomment-82263...

tl;dr: Go uses casts to coerce values to the correct types, which means you couldn't get pointers to number literals for non-default number types.

Re: Proposal: expression to create pointer to simple types

#92

Post by Laremere »

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…

I asked that in the Github issue, response here: https://github.com/golang/go/issues/45624#issuecomment-82259... With my reply (and further exploration) here: https://github.com/golang/go/issues/45624#issuecomment-82263...

Re: Proposal: expression to create pointer to simple types

#93

Post by howeyc »

friseurtermin wrote: post #86
fred256 wrote: post #30

Earlier quoted context omitted.

From the language specification: > Numeric constants represent exact values of arbitrary precision and do not overflow.

Ok I think I'm not understanding this correctly then. Why does this return an error? package main import ( "fmt" ) const tst = 1000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 func main() { fmt.Println("%v", tst) } Error: ./prog.go:16:17: constant 100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000…

https://golang.org/ref/spec#Constants

> An untyped constant has a default type which is the type to which the constant is implicitly converted in contexts where a typed value is required.

The default type for a number (integer) is int. If you were to add a period in that long string of zeros, the default for floating-point is float64.

Re: Proposal: expression to create pointer to simple types

#94

Post by catlifeonmars »

coder543 wrote: post #66
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, that does not cause a heap allocation on its own. If other lines of code in that function caused a pointer to that value to escape the lifetime of the current function's stack frame, the compiler would determine that it has to be heap allocated instead. I believe the person you are replying to was making a confusing point about some hand wavy notion of "any kind of allocation", which includes stack allocations...…

Ah, that makes much more sense!

Re: Proposal: expression to create pointer to simple types

#95

Post by throwaway19937 »

tssva wrote: post #38
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.

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?

AFAIK there aren't specific guidelines but posts like the grandparent are normally moderated down. (https://news.ycombinator.com/item?id=2965166) is an example of well-received humor; it's one of the top rated posts.

Re: Proposal: expression to create pointer to simple types

#96

Post by c3534l »

furyofantares wrote: post #64
not_knuth wrote: post #12

Earlier quoted context omitted.

IIRC Tim Berners-Lee also rather amusingly called himself a "Web Developer" at a conference.

There's a double connotation being played with there, a web developer vs the web developer

Yeah, I think that was the "rather amusingly" part.

Re: Proposal: expression to create pointer to simple types

#97

Post by Groxx »

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.

Well. It would reduce it to 1 (PtrTo) instead of [however many]. And unless they also add a new top-level func like that, it's still a `package.PtrTo` rather than `&`. And `&`'s special abilities on only composite literals remains.

Re: Proposal: expression to create pointer to simple types

#98

Post by [deleted] »

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.

[deleted]

Re: Proposal: expression to create pointer to simple types

#99

Post by jerf »

coder543 wrote: post #60
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…

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

You file a good complaint, and I should clarify. What I mean is more like Go is secretly quite explicit about its allocations, if I may. It superficially looks like it doesn't really care with a variety of syntax glosses that can make it look like it's more like a scripting language where it doesn't care, but it actually does care quite a lot even at the syntax level, and if you dig past the syntax glosses, it is actually explicit about what gets allocated. It doesn't successfully hide it from you like a scripting language does.

Also, allocations are just... allocations. Go qua Go doesn't have stack vs. heap, and it's a mistake to care except when optimizing. So in Go qua Go, it isn't an issue that it may "reuse" a particular address, because in Go qua Go you can't witness that anyhow. (If you try to keep a pointer around to witness it with, you'll keep the thing pointed to alive.) From Go's perspective, it's still an allocation even if the implementation manages to re-use a particular memory address to do so.

I'm talking about the runtime Go implements here, not the implementation.

This actually took me some years to correctly internalize, for what it's worth. It does a "good" job of glossing over things. However, if you really poke at it, allocations are still explicit. They just may not look like what you are used to from other languages.

Re: Proposal: expression to create pointer to simple types

#100

Post by [deleted] »

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.

[deleted]
Post reply on HN