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

71–80 of 110 posts

Re: Proposal: expression to create pointer to simple types

#71

Post by steveklabnik »

masklinn wrote: post #54
gowld wrote: post #40

Earlier quoted context omitted.

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

"implicitly allocate" is slightly misleading, imho. It's promoted to a static. There's no malloc involved.

Re: Proposal: expression to create pointer to simple types

#72

Post by fanf2 »

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?

Yes, if f() returns the type T then you can write

    &(T[]){ f() }
The type in brackets needs to be an array so that if f() returns a struct then the initializer list has the right shape. If T is a simple type then you can drop the [].

Re: Proposal: expression to create pointer to simple types

#73

Post by masklinn »

steveklabnik wrote: post #71
masklinn wrote: post #54

Earlier quoted context omitted.

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

"implicitly allocate" is slightly misleading, imho. It's promoted to a static. There's no malloc involved.

> "implicitly allocate" is slightly misleading

Maybe. I just meant that storage is created implicitly (static or stackframe depending on the case), then a reference is created to that.,

Re: Proposal: expression to create pointer to simple types

#74

Post by kevincox »

masklinn wrote: post #63
kevincox wrote: post #55

Earlier quoted context omitted.

`&` 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()) c…

> 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) I think assigning to a pointer would cause an escape. Just taking a reference wouldn't though, the reference still has to escape (of course you'd usually take a reference so that it can escape but that's not always the case, especially with…

What do you mean by assigning to a pointer? You can only assign a pointer value to a pointer variable and you need to get that pointer from & IIUC.

Re: Proposal: expression to create pointer to simple types

#75

Post by masklinn »

kevincox wrote: post #74
masklinn wrote: post #63

Earlier quoted context omitted.

> 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) I think assigning to a pointer would cause an escape. Just taking a reference wouldn't though, the reference still has to escape (of course you'd usually take a reference so that it can escape but that's not always the case, especially with…

What do you mean by assigning to a pointer? You can only assign a pointer value to a pointer variable and you need to get that pointer from & IIUC.

> What do you mean by assigning to a pointer?

    *x = y

Re: Proposal: expression to create pointer to simple types

#76

Post by zeeboo »

masklinn wrote: post #70
zeeboo wrote: post #68

Earlier quoted context omitted.

> It doesn't (have to) invalidate the pointer though. When resized the map's content get copied to a new backing buffer, the pointer can keep pointing to the old buffer. That's true, but I don't think it's very comparable to slices. With slices, you have to explicitly reallocate either by creating a whole new slice or using append. Reslicing, indexing, or other operations do not reallocate. On the other hand, maps ma…

> That's true, but I don't think it's very comparable to slices It's exactly the same. > With slices, you have to explicitly reallocate either by creating a whole new slice or using append. That's a distinction without a difference. `append` does not "explicitly reallocate", it may or may not reallocate, you've no idea. Even if the backing array is full, it might be realloc'd in-place. > On the other hand, maps may e…

> That's a distinction without a difference. `append` does not "explicitly reallocate", it may or may not reallocate, you've no idea. Even if the backing array is full, it might be realloc'd in-place.

Maybe to you, but to me, a pointer going from modifying the value inside of the map to no longer modifying the value inside of the map during any operation is quite a bit different than requiring a reassignment of the slice header. In other words:

    x := make([]int, 5)
    y := &x[0]
    x[3] = 8
    *y = 5
    print(x[0]) // always prints 5
as compared to

    x := make(map[int]int)
    y = &x[0] // btw, is this even valid? let's assume it implicitly does x[0] = 0
    x[3] = 8
    *y = 5
    print(x[0]) // maybe sometimes prints 5?
is meaningfully different. For slices, we know that x[0] will always print 5 until the value of x is reassigned in some way.

> Also technically nothing prevents a GC from reallocating the slice.

It would have the same problem the map does: you'd have to update any pointers into the slice to point to the new slice, otherwise the semantics of the program changes. That is not something the GC currently does, and would require an awful lot of metadata and scanning.

> I've never heard of a hashmap implementation which would do otherwise.

I'm not sure what this is referring to. I agree every map implementation has to reallocate the backing store of values periodically. I was trying to say that keeping the flexibility to reallocate the backing store of the map during GC means that you cannot choose the "writes through pointer are observed in the map" option (at least without a lot of complication around updating pointers) because as a programmer, you would not be able to know if it would do that or not, which is a fairly useless primitive.

Re: Proposal: expression to create pointer to simple types

#77

Post by Smaug123 »

phoe-krk wrote: post #52

> (...) that has the nasty problem that 3 does not have a type (...) How is that possible? At least in Common Lisp, all literal objects have types, and the same is true of C from what I have just checked.

It doesn't have a type in Haskell, from a certain point of view. `3` is polymorphic.

Prelude> :t 3

3 :: Num p => p

Re: Proposal: expression to create pointer to simple types

#78

Post by tome »

Smaug123 wrote: post #77
phoe-krk wrote: post #52

> (...) that has the nasty problem that 3 does not have a type (...) How is that possible? At least in Common Lisp, all literal objects have types, and the same is true of C from what I have just checked.

It doesn't have a type in Haskell, from a certain point of view. `3` is polymorphic. Prelude> :t 3 3 :: Num p => p

It does have a type. You just wrote it down!

Re: Proposal: expression to create pointer to simple types

#79

Post by anon_tor_12345 »

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.

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?
Post reply on HN