Support default values for object properties

Example:

type MyObj = object
    id: int = generateUniqueId()
    x: int = 42
    stuff: seq[string] = @[]

I can think at least the following benefits:

• Faster prototyping (less typing when no need to write newMyObj or initMyObj procs)
• Makes it harder to misuse objects (for example when using some library for the first time)
• Easier generics (with a stupid example):

proc doSomethingGeneric[T](): T =
    assert result.x == 42
    assert result.stuff != nil

discard doSomethingGeneric[MyObj]()

[FedericoCeratto]

Relevant: http://forum.nim-lang.org/t/703

EDIT: URL updated

[ConsoleTVs]

This still need to be a feature 3 years later

[CodeDoes]

https://web.archive.org/web/20150921132359/http://forum.nim-lang.org:80/t/703

[stefanos82]

@dom96 The reason @FedericoCeratto's link does not work is because it ends with a forward slash.

If I'm not mistaken, you mentioned this issue in IRC, correct?

[gitnik]

I'm having a hard time understand how something as fundamental as this is considered low priority

[krux02]

It is by design that Nim does not need constructors. Objects are by default initialized with 0 memory and it is the programmers job to create the type in a way so that the 0 memory isn't an illegal state of the object. Since seq and string are now by default empty and not nil anymore, the biggest reason to have inititializers/constructors is now gone. Currently I don't see any good reason to add destructors that justifies the costs of having destructors.

Nim isn't the only language that works this way, for example Go works exactly the same way.

[timotheecour]

Currently I don't see any good reason to add destructors that justifies the costs of having destructors.

what do you mean by costs? if you're talking about runtime cost overhead, I don't think this is the case; it would be a zero-cost abstraction when no custom constructor is defined for a type
if you mean implementation complexity, that's a different story but it'd be worth it IMO to simplify a number of patterns ala C++ RAII

[krux02]

I am not talking about runtime costs. I am talking about costs to implement it, fixing the bugs and conflics that arise from it. Live with the fact that constructors are a thing and value types are no longer all zero anymore. Did you ever watch a lesson about generic exception safe initialization in c++? It's nuts and not worth it. memset to 0 can't raise an exception.

[timotheecour]

the alternative is to make initialization explicit, eg:
https://github.com/nim-lang/Nim/issues/8855
or
https://github.com/nim-lang/Nim/issues/7832

IIUC that would alleviate much of the complexity issues you're referring to.

[dom96]

I'm having a hard time understand how something as fundamental as this is considered low priority

This isn't fundamental. There is plenty of languages that don't allow this. Plus this is yet another feature that is easily doable within the confines of existing language features: just use a constructor procedure.

[timotheecour]

this is fundamental.

@dom96
I think it is, for several reasons (beyond eliminating much boilerplate) including not to break the type system guarantees, see below.

I am not talking about runtime costs. I am talking about costs to implement it, fixing the bugs and conflics that arise from it

@krux02
you're simply shifting around the complexity to the user, it's never a good tradeoff.

Did you ever watch a lesson about generic exception safe initialization in c++? It's nuts and not worth it. memset to 0 can't raise an exception.

not relevant. We're talking (or at least in my version of this RFC) about default values known at CT, whereas C++ has to deal with RT initialization. Implementation is not complex (in fact we already have nim-lang/Nim#12378).
Implications are that for types that are not binary-zero-initialized, compiler will use memcpy instead of memset, and variable initializers in cgen binary could end up in .data or .rodata section instead of .bss, but that's to be expected.

without this feature, the type system is broken

There's another important use case not mentioned here: type safety guarantees.
Some Nim type system guarantees evaporate because of this, eg range objects, enum starting at some offset, or any type that (recursively) contains any such type. eg:

block:
  type R = range[10..13]
  doAssert R.default == 0 # broken
  var a: R
  doAssert a == 0  # broken

  type Foo = enum k1 = 10, k2 # not even enum with holes
  var b: Foo
  doAssert b.ord == 0  # broken
  doAssert $b == "0 (invalid data!)"  # broken

  ## affects any type that has a (sub-) member with non-valid-default
  type Bar = object
    a1: Foo
    a2: R

  # var c: Bar # this doesn't even compile
  var c = default(Bar) # that does compile, but still broken
  doAssert $c == "(a1: 0 (invalid data!), a2: 0)"

note that some of these generate a warning (UnsafeDefault) but preventing these from working is not an option (breaks generic code including serialization/deserialization, among other use case)

real life example

complications arising from DateTime, which contains both range[1..31] and enum with offset (see #211)