Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Why require types have a meaningful zero value?

It's not necessary for value semantics. You can require that values be initialized and the machinery for that doesn't seem that bad.

Zero values seem as arbitrary as requiring all types be equatable.



I'm really not sure what your comment means, sorry.


So, my understanding is that: 1. Unless otherwise initialized, types have a zero value in go. For pointer types that zero value is nil. 2. It's encouraged for this to be meaningful. That's opposed to say java, python, or C++ where invoking a method on a null object is a runtime error (or undefined behavior). So for example, appending to a 'nil' slice is the rough equivalent of trying to add to a null List in java. I don't see how the go approach makes anything simpler.

Value semantics are simply that the value of an object is all that matters. For example, two int objects '5' are the same from a value-semantic perspective. I guess this implies all objects have some value. This requirement can be satisfied by requiring they be explicitly initialized.

Equatability is a requirement of objects in java. Not all types of objects are equatable beyond their identity (some unique identifier) though. For example, how do you equate two functions? To me this parallels the decision in go to make zero values a thing beyond a runtime error.


> I don't see how the go approach makes anything simpler.

The "append" builtin doesn't "invoke" anything on the nil pointer. It's more or less (in Java-ish pseudocode):

  static Slice<T> append(Slice<T> s, items ...T) {
      if (s == null) {
          Slice<T> newSlice = new Slice<T>(items.size())
          newSlice.pushBack(items)
          return newSlice
      }
      if s.hasEnoughCapcityFor(items.size()) {
          s.pushBack(items)
          return s
      }
      Slice<T> newSlice = new Slice<T>(s.size() + items.size())
      newSlice.pushBack(s)
      newSlice.pushBack(items)
      return newSlice
  }
which is a perfectly reasonable utility function in pretty much any language. See, e.g., realloc(3).

> Value semantics are simply that the value of an object is all that matters. For example, two int objects '5' are the same from a value-semantic perspective. I guess this implies all objects have some value. > > Equatability is a requirement of objects in java. Not all types of objects are equatable beyond their identity (some unique identifier) though. For example, how do you equate two functions? To me this parallels the decision in go to make zero values a thing beyond a runtime error.

In Go, having a "meaningful" zero value for a type means that you don't need to initialize the type before using it. For example:

  var b bytes.Buffer
  b.WriteString("hello, world")
instead of

  b := bytes.NewBuffer(nil)
  b.WriteString("hello, world")
Or, as another example:

  type BinarySearchTree struct { ... }

  func (b *BinarySearchTree) Contains(key string) bool {
      if b == nil {
          return false
      }
      [...]
  }
Go makes this possible by not requiring constructors like other languages do (e.g., Java).


You can evoke a method on a nil object in Go because it handles methods as functions that have an extra first parameter. take a look here: https://go.dev/play/p/2SRU26mvfnL




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: