5 ms·

> Using a pointer adds an extra heap allocation, though. If you want to dereference it immediately (as they seem to want to in the post), this isn't really goi

> Using a pointer adds an extra heap allocation, though. If you want to dereference it immediately (as they seem to want to in the post), this isn't really going to affect you. You probably want to pass around a pointer, anyway, so that you're not copying values over each time. > The right thing would be to use a Nullable<T> type and define a custom marshaller once and for all... but Go doesn't have generics, so you can't do that. Sure you can - that's literally what the NullBool, etc. types do A pointer to a string IS a 'Nullable<String>' - what they need to do is define a way to unwrap this cleanly, which is easy.

pcwalton 14y ago
> If you want to dereference it immediately (as they seem to want to in the post), this isn't really going to affect you. You probably want to pass around a pointer, anyway, so that you're not copying values over each time. Sure, I'm not saying that the extra allocation will always matter. In most cases it won't. My point is just that this type system workaround does cost some performance. For example, a heap-allocated struct that contains two nullable ints using the pointer trick has 3 heap allocations, not one. > Sure you can - that's literally what the NullBool, etc. types do But that has to be done for each type. If you define a custom type Foo and want a nullable version, you have to write the NullFoo boilerplate yourself. This is what generics are for.
- chimeracoder 14y ago
  > If you define a custom type Foo and want a nullable version, you have to write the NullFoo boilerplate yourself. This is what generics are for. I don't want to descend down the rabbit hole of 'Go doesn't have generics', but as I said above, in this case, pointers do exactly what is needed.
  - kevingadd 14y ago
    A pointer to T is not the same as Nullable<T>. There are many important differences. The expressible values for a Nullable<T> are, in theory, the following: A valid instance of T, or Null The expressible values for a pointer-to-T are, in theory, the following: A null pointer (pointer-to-0) A pointer to a valid instance of T A pointer to a previously valid, but now invalid because it was freed, instance of T A pointer to an arbitrary location in memory In systems programming (the space Go is presumably designed to be most useful for), the distinction between valid and invalid data is pretty important, so it's a little lazy to say 'just use pointers' when there are examples out there of safer, more efficient alternatives.
    - eurleif 14y ago
      >The expressible values for a pointer-to-T are, in theory, the following: A null pointer (pointer-to-0) A pointer to a valid instance of T A pointer to a previously valid, but now invalid because it was freed, instance of T A pointer to an arbitrary location in memory In C. Go has garbage collection, and no pointer arithmetic, so that's not the case in Go.
      - kevingadd 14y ago
        If you think a garbage collector and the lack of pointer arithmetic protect you from heap corruption bugs and developers deciding they're smart enough to manually manage memory for some extra speed, I've got some bad news for you. ;)
        eurleif 14y ago
        How do you expect them to do that when the language doesn't allow it? Can you show an example of Go code which creates an invalid pointer?
        Symmetry 14y ago
        There's a library called "unsafe" explicitely for this. I think it's reasonable to expect people to generally not use it, though. http://golang.org/pkg/unsafe/ http://golang.org/pkg/unsafe/
        eurleif 14y ago
        As far as I know, it can only create a pointer of type A that actually points to a value of type B, not reference unallocated/deallocated memory. Nullable<T> could do that too if the language allowed it.
        lagom 14y ago
        It's definitely possible to access unallocated memory e.g., // p points to address 1000 p := (*int)(unsafe.Pointer(uintptr(1000))) Of course, this is why use of the unsafe package is heavily discouraged.

pcwalton 14y ago

> If you want to dereference it immediately (as they seem to want to in the post), this isn't really going to affect you. You probably want to pass around a pointer, anyway, so that you're not copying values over each time. Sure, I'm not saying that the extra allocation will always matter. In most cases it won't. My point is just that this type system workaround does cost some performance. For example, a heap-allocated struct that contains two nullable ints using the pointer trick has 3 heap allocations, not one. > Sure you can - that's literally what the NullBool, etc. types do But that has to be done for each type. If you define a custom type Foo and want a nullable version, you have to write the NullFoo boilerplate yourself. This is what generics are for.

chimeracoder 14y ago
> If you define a custom type Foo and want a nullable version, you have to write the NullFoo boilerplate yourself. This is what generics are for. I don't want to descend down the rabbit hole of 'Go doesn't have generics', but as I said above, in this case, pointers do exactly what is needed.
- kevingadd 14y ago
  A pointer to T is not the same as Nullable<T>. There are many important differences. The expressible values for a Nullable<T> are, in theory, the following: A valid instance of T, or Null The expressible values for a pointer-to-T are, in theory, the following: A null pointer (pointer-to-0) A pointer to a valid instance of T A pointer to a previously valid, but now invalid because it was freed, instance of T A pointer to an arbitrary location in memory In systems programming (the space Go is presumably designed to be most useful for), the distinction between valid and invalid data is pretty important, so it's a little lazy to say 'just use pointers' when there are examples out there of safer, more efficient alternatives.
  - eurleif 14y ago
    >The expressible values for a pointer-to-T are, in theory, the following: A null pointer (pointer-to-0) A pointer to a valid instance of T A pointer to a previously valid, but now invalid because it was freed, instance of T A pointer to an arbitrary location in memory In C. Go has garbage collection, and no pointer arithmetic, so that's not the case in Go.
    - kevingadd 14y ago
      If you think a garbage collector and the lack of pointer arithmetic protect you from heap corruption bugs and developers deciding they're smart enough to manually manage memory for some extra speed, I've got some bad news for you. ;)
      - eurleif 14y ago
        How do you expect them to do that when the language doesn't allow it? Can you show an example of Go code which creates an invalid pointer?
        Symmetry 14y ago
        There's a library called "unsafe" explicitely for this. I think it's reasonable to expect people to generally not use it, though. http://golang.org/pkg/unsafe/ http://golang.org/pkg/unsafe/
        eurleif 14y ago
        As far as I know, it can only create a pointer of type A that actually points to a value of type B, not reference unallocated/deallocated memory. Nullable<T> could do that too if the language allowed it.
        lagom 14y ago
        It's definitely possible to access unallocated memory e.g., // p points to address 1000 p := (*int)(unsafe.Pointer(uintptr(1000))) Of course, this is why use of the unsafe package is heavily discouraged.