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

41–50 of 110 posts

Re: Proposal: expression to create pointer to simple types

#41

Post by gowld »

fred256 wrote: post #31
gowld wrote: post #28

Earlier quoted context omitted.

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.

Aha, lossy compression syntax!

Re: Proposal: expression to create pointer to simple types

#42

Post by kevincox »

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?

No, but in C you can't apply `&` to any stack value and "automagically" pop it onto the heap. Or from another point of view everything in Go is logically on the heap, the compiler just optimizes values that don't have their address taken to live on the stack.

In C:

  int *f() {
    int x = 0;
    return &x;
  }
It works, but it is wrong. The C type system isn't smart enough to realize the lifetime of x in this case. It is not allowed for a function return because C does have the concept of a temporary value so it is disallowed because it is basically always incorrect to do so.

Note that C++ does somewhat allow this with lifetime extension. It is somewhat like what I expected Go to do, except because lifetime extension only extends to the enclosing block it is more of a footgun. With a dynamic tracing garbage collector like Go it not a footgun.

Re: Proposal: expression to create pointer to simple types

#43

Post by kevincox »

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

Re: Proposal: expression to create pointer to simple types

#44

Post by kevincox »

catlifeonmars wrote: post #35
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’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.

Re: Proposal: expression to create pointer to simple types

#45

Post by Waterluvian »

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

There's the General who responds, "You don't need to see my ID. Don't you know who I am? Who's your CO?!"

And the General who responds, "Right. Well done."

Re: Proposal: expression to create pointer to simple types

#46

Post by Graffur »

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?

In this case it seems pretty clear. If you're not sure you could try reading more posts before posting. You should be able to pick up the general vibe/tone.

Re: Proposal: expression to create pointer to simple types

#47

Post by fuzzer37 »

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.

I thought it was funny

Re: Proposal: expression to create pointer to simple types

#49

Post by tssva »

Graffur wrote: post #46
tssva wrote: post #38

Earlier quoted context omitted.

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?

In this case it seems pretty clear. If you're not sure you could try reading more posts before posting. You should be able to pick up the general vibe/tone.

I found the comment funny. Since the purpose of a joke is to be funny this makes it high quality as far as I am concerned. If you didn't find it funny, I guess you would consider it low quality. The point is that judging comedy and jokes is so subjective and personal as to make any such rule regarding quality a joke itself. You can ban all jokes or mandate that jokes can't contain racist, sexist, ageist, or other such potentially offensive content but trying to filter jokes based upon quality is a bit ridiculous.

Re: Proposal: expression to create pointer to simple types

#50

Post by zibzab »

aloisdg wrote: post #7
tempest_ wrote: post #4

Earlier quoted context omitted.

I found it more amusing that he listed 8 languages that he has experience with and then went out of his way to exclude JavaScript.

When you know JavaScript enough to be able to say that you don't know JavaScript.

That's basically me and C++, and I suspect I am not alone
Post reply on HN