From what i understood I do not think it is a backwards compatible change for types that already have an init function defined before the new language change as code (e.g. var f frac) that does not have a matching constructor after the change to create an instance of the type will not compile anymore.

Go is usually defined in a way to avoid hiding expensive operations behind simple constructs e.g. for f:=frac{x, 0} it is not obvious that an init function is called that might do all kinds of things up to never returning.

Its also allows to break simple language constructs in the distance by adding code. By adding an init function with arguments all var declarations maybe invalid for that type.

Note that go does not currently allow to define a method on the type with same name and different number of parameters so that would be another language change unless it would be a special exception for init only.

There are other open questions for the proposal. If a value e.g. for map access for which a key is not present needs to be created or a value for a bare return would this also call a matching constructor or use the zero value or would it fail to compile as there may be no constructor with no arguments?

In general I think we cant avoid misusing a type as the programmer can always use unsafe and other workarounds to not construct a type through the init function if they otherwise avoid the documented API contract for use of the type.

The general Idea of constructors and destructors has been previously discussed in proposal #21737 which was rejected.

Related to #21737.

Go is designed to be verbose so that you know exactly what happens. Having var f frac execute arbitrary code is not intuitive to me

I think it's great that you are trying to ensure the internal consistency of instances of your Frac struct. In Go we try to make default (zero initialised) instances be valid but this is not always possible.

However there is a mechanism to do what you want already in Go, assuming Frac is in its own package, which it probably should be (even if just an internal package).

You simply need to make the type unexported from the package. Then have the exported "constructor" return an instance of the type. For example:

  package frac

  type frac struct { n, d int }

  func New(n, d int) frac { ...

Then from another package:

  f := frac.New(1, 2)
  
  f := frac.frac{}  // illegal

This is a backward-compatible proposal to introduce new init functions to named types as its constructors. When initiate new instance of some type, if the type has no init function, the go compiler initiate it with its default ZERO value, but if the type has any explicit init function, the compiler must call its matched constructor to initiate the instance.

This seems like overkill for this specific use-case. What you're asking for has the same problems as operator overloading. Wouldn't it be easier to just allow the user to specify alternative defaults for a type? For example,

type Frac struct {
  n int
  d int = 1
}

Now the 'zero' value for Frac.d is 1 instead of 0.

I'm not really arguing in favor of this, for the record; things like this have been proposed and shot-down before, if I remember right. I'm just trying to provide a simpler alternative that doesn't involve hidden functions getting run without the user explicitly asking for it.

When this has mattered for me, I end up doing something like:

type T struct {
    x, y                          int
    userProperlyCalledConstructor bool
}

func NewT(x, y int) *T { return &T{x, y, true} }

func (t *T) M() {
   if !t.userProperlyCalledConstructor {
      panic("you didn't use the NewT constructor")
   }
   // ....
}

I was also amused by @AndrewWPhillips's suggestion which is usually just a sign of bad API design. I never considered that pattern might have a valid use!

We appreciate the problem that this issue is trying to solve. It might be nice to have better ways to ensure that a type can only be set to valid values. But this particular approach of requiring a constructor to run implicitly does not seem to fit the spirit of the language. It's also not clear how to handle composite literals with field keys, as in Frac{d:0}. And it's not clear how to handle composite literals of more complex types, in which some fields of the outer struct are themselves structs, etc.

Has there been consideration of defined-type default initializers?
If not would that merit a separate proposal?

type T struct {
   i int
   s []byte
}
init T{i: 42, s: make([]byte, 21)} // allow constants and make(T, constant)

type I int
init I(1)
default I(1) // alternative keyword

func f() {
   var t T // t.i == 42 && len(t.s) == 21
}

@networkimprov Default initializers as you describe them address a slightly different problem, in that they are restricted in the values they can set. I can't recall the idea having been proposed before. It's not clear to me that it's worth the cost.