Object init shorthand

[dom96]

Consider the following object type:

type
  User = object
    name: string
    age: int
    last_online: float

It's very common to write a constructor for such types, some may have many more fields than the above, having to write the name of each field gets tedious:

proc initUser(name: string, age: int): User =
  User(
    name: name,
    age: age,
    last_online: epochTime()
  )

This RFC proposes to implement a short-hand syntax for the object construction syntax to simplify this code:

proc initUser(name: string, age: int): User =
  User(
    name,
    age,
    last_online: epochTime()
  )

The variable names have to match that of the field name, so User(foo, age) won't work even if foo is a string.

[konsumlamm]

Rust also has this shorthand syntax and I'm not aware of any problems with it.

[timotheecour]

Here's my counter-proposal, which I used in nim-lang/fusion#32 + other places (but the proposal below improves upon it to allow more flexibility)

# in sugar.nim:
import std/macros

macro objInit*(obj: typed, a: varargs[untyped]): untyped =
  ##[
  Generates an object constructor call from a list of fields.
  ]##
  result = nnkObjConstr.newTree(obj)
  for ai in a:
    case ai.kind
    of nnkExprEqExpr:
      result.add nnkExprColonExpr.newTree(ai[0], ai[1])
    of nnkIdent:
      result.add nnkExprColonExpr.newTree(ai, ai)
    else:
      doAssert false, $ai.kind

usage

type
  User = object
    name: string
    age: int
    last_online: float

proc init(T: typedesc[User], name: string, age: int, bar: int): T =
  T.objInit(name, age, last_online = bar.float * 10.0)

doAssert User.init("ab", 3, 4) == User(name: "ab", age: 3, last_online: 40.0)

benefits

• DRY: the type name User is used only once in the init declaration in user code
• can be used in generic code, unlike initUser:

proc baz(a: T) =
  let b = T.init(...)

• doesn't need compiler support and more explicit (ie, less magic) than supporting User(name, age), hence can be used in stdlib without breaking parser for nim versions prior to this change
• allows custom fields as demonstrated above (the last_online = bar.float * 10.0)

[haxscramper]

This can easily be done using macro, so I don't think there is a need for dedicated compiler support. Also, Type(arg1, arg2) mixes with proc(arg1, arg2) syntax, while T.init is more explicit, and also works with generics.

What nim really lacks is a standardized way to construct objects, and I don't think there is a need to add yet another one. We already have quite a few, all with their own limitations

• MyType(field: a, field2: b) - very verbose, does not work with generics, you can't set default values (User-defined implicit initialization hooks #252), you can't validate input values on construction.
• newT(), initT() - does not work with generics, requires manual implementation (which can be done using macro), but does support default values and input validation.
• init[T](t: typedesc[T]), new[T](t: typedesc[T]) - also requires manual implementation, not widely used, but IMO this is the best option as it supports generics, which none of the previous versions do, also matches default[T](t: typedesc[T]).

If default(T) is supposed to be a default way to construct objects (it is still not injected in var: declarations, but can at least be used in different templates to make them work with {.requiresinit.}), then we should also consider init(T).

---

Also, how does this proposal intend to deal with inheritance, when sections, variant objects or different combinations of them (like inheritance from variant object, or multiple fields, or #368)?

[Araq]

A couple of general remarks:

• The constructor syntax would work better with the object field = value default value support. (It's an accepted RFC...)
• Likewise, we should make the constructors infer generic types.
• Some support for in-place construction ("inplace new") like in C++ would be really nice.
• Wrapping the constructor in a proc can lose crucial information for precise alias analysis.
• Shortening the construction syntax ... Sure, why not, but not important for me personally.

[haxscramper]

By in-place construction, do you mean aggregate initialization?

struct S {
    int x;
    struct Foo {
        int i;
        int j;
        int a[3];
    } b;
};
 
int main()
{
    S s1 = { 1, { 2, 3, {4, 5, 6} } };

[Araq]

No, mean "placement new":

  T* tptr = new(buf) T; // Construct a `T` object, placing it directly into your 
                        // pre-allocated storage at memory address `buf`.

It's useful for optimizing myseq.add Obj(field: value, ...)

[Varriount]

Just want to put this out here: https://docs.python.org/3/library/dataclasses.html

It strikes me that a similar module would solve the "common initialization logic" problem, as well as some other common requests.

[juancarlospaco]

I am not sure this belongs in the stdlib.
Also it seems relatively simple to implement manually when needed.

[Varriount]

I am not sure this belongs in the stdlib.
Also it seems relatively simple to implement manually when needed.

I can see a "dataclasses"-like module being more effective as part of the standard library, because it would (likely) set a de facto standard. A problem with encapsulating interoperability mechanisms in an external module is its effectiveness relies on how ubiquitously it is used. If the community doesn't gather around a single module, then this has the potential to happen.

(Please note the use of "likely", "potential", etc. in the paragraph above. The above is a possible outcome, but not a certainty)

[Clonkk]

I'm surprised noone mentionned https://github.com/beef331/constructor#construct

Creating new object sure could use some quality of life stuff; the question is whether or not syntactic sugar has its place in the stdlib.

[disruptek]

Just once, it'd be nice to see a thing added to stdlib because it's /annoyingly/ absent and /everyone/ has to depend upon it as a requirement which /rarely/ changes and works with /all/ supported compiler versions.

Unlike, for example, this case, where neither the syntax nor the implementation will likely satisfy everyone, so it just becomes an immediate burden. But by all means, bike shed away.

What if the burden was merely in adding it as a requirement to your package manager? Unthinkable? Really?

[beef331]

The present object constructor syntax(aside from not inferring generics) is fine, if you something more sweet you can easily write your own or use a package(as disruptek alluded to). As such here is yet another way to construct objects in a DRY manner cause I apparently love volume.

import constructor/constructor
type
  User = object
    name: string
    age: int
    lastOnline: float

proc initUser*(name: string, age: int): User {.constr.} = discard

proc init(T: typedesc[User], name: string, age: int) {.constr.} =
  let lastOnline = 30f

assert initUser("hello", 10) == User(name: "hello", lastOnline: 0f, age: 10)
assert User.init("hello", 30) == User(name: "hello", lastOnline: 30f, age: 30)

[demotomohiro]

I also wrote a macro that create a object type definition from a constructor proc:
https://github.com/demotomohiro/objectDef

But I'm not using it so much. Standard Nim way to define an object type and a constructor proc is fine.

[ZoomRmc]

Seeing as @ringabout is already working on an implementation, I'd like to consider the potential issues with a simple positional syntax proposed.

Here's the example @ringabout left on the forum:

type
  Vector = object
    a: int = 1
    b, c: int

block: # positional construction
  var x = Vector(1, 2, 3)
  echo x

This example is bad at demonstrating the usefulness of shorthand constructs - why not use a tuple? - and good ad demonstrating its cons. If it's really an object with all fields of the same type, as soon as anyone touches the declaration and changes the order of fields, the code will break everywhere the object's used with no warnings. What you get is a weird tuple.

If the fields are of mixed types, there's still a chance (albeit much smaller one.) the code will compile and break. The language should resist accommodating more syntax constructs with such qualities. Relying on order for tuples and procs is enough of a footgun.

Named fields are an annoyance, but they are a correctness guarantee.

This RFC proposes allowing for a short-version construction only if the field name matches the variable name. And this looks reasonable enough. #21559 doesn't implement this RFC and should be discussed separately, possibly with a voting/comparison with different approaches:

• Positional constructs in the language
• Positional constructs in sugar
• Name-matched constructs in the language
• Name-matched constructs in sugar
• Other options
• Leave as is.

Personally, I think this is more an issue of tooling. Proper autocompletion and tooltips would reduce the crux of the problem to just a few tab presses for each construction.