[typetraits] Error when printing a tuple's type using t.type.name when the tuple has a field called "name"

[kaushalmodi]

Below works:

import strformat, typetraits
type Person = tuple[name: string, age:int]
let person: Person = ("Peter", 30)
echo fmt"Tuple person of type {$person.type} = {person}"

Tuple person of type Person = (name: "Peter", age: 30)

Below fails:

import strformat, typetraits
type Person = tuple[name: string, age:int]
let person: Person = ("Peter", 30)
echo fmt"Tuple person of type {person.type.name} = {person}"

Hint: typetraits [Processing]
nim_src_2f8wWD.nim(7, 9) template/generic instantiation from here
lib/pure/strformat.nim(260, 8) Error: type mismatch: got <string, type string>
but expected one of:
proc add(x: var string; y: string)
  first type mismatch at position: 2
  required type: string
  but expression 'type(person).name' is of type: type string
proc add(x: var string; y: char)
  first type mismatch at position: 2
  required type: char
  but expression 'type(person).name' is of type: type string
proc add(result: var string; x: int64)
  first type mismatch at position: 2
  required type: int64
  but expression 'type(person).name' is of type: type string
proc add(result: var string; x: float)
  first type mismatch at position: 2
  required type: float
  but expression 'type(person).name' is of type: type string
proc add(x: var string; y: cstring)
  first type mismatch at position: 2
  required type: cstring
  but expression 'type(person).name' is of type: type string
proc add[T](x: var seq[T]; y: openArray[T])
  first type mismatch at position: 1
  required type: var seq[T]
  but expression 'fmtRes218041' is of type: string
proc add[T](x: var seq[T]; y: T)
  first type mismatch at position: 1
  required type: var seq[T]
  but expression 'fmtRes218041' is of type: string

expression: add(fmtRes218041, type(person).name)

type.name works again if I change the tuple field name to anything
but name:

import strformat, typetraits
type Person = tuple[namex: string, age:int]
let person: Person = ("Peter", 30)
echo fmt"Tuple person of type {person.type.name} = {person}"

Tuple person of type Person = (namex: "Peter", age: 30)

[Vindaar]

Just played around with this and thought I'd share:

In case you still want to be able to print such a type, as a workaround you can perform the calls like

echo fmt"Tuple person of type {name(type(person))} = {person}"
echo fmt"Tuple person of type {name(person.type)} = {person}"
# or simply:
echo fmt"Tuple person of type {$person.type} = {person}"

If you look at the different ways to call the function

echo name(person.type)  # Person, as expected.
echo name(type(person)) # Person, as expected.
echo person.type.name   # string, weird (?), since expands to type(person).name.
                        # for some reason this is just:
                        # type(person.name) == type(string)
echo person.name.type   # string, as expected, since field `name` is type string

I'm pretty confused by the person.type.name to type(person).name to type(person.name) rewrite to be honest. But that might just be my misunderstanding of Nim's rewrite rules.

The reason it doesn't compile then boils down to the the fact that types cannot be printed (which is why the name proc in typetraits exists in the first place of course).

[timotheecour]

should we close? I don't think there's a bug here, works as intended. eg:

  type Foo = object
    a1: float
  doAssert Foo.a1 is float
  var x: Foo.a1
  doAssert x == 0.0
  var foo: Foo
  doAssert foo.type.a1 is float

[kaushalmodi]

@timotheecour the "bug" here is that the confusion happening between the name proc in typetraits and the name field in the tuple in my example.

Below works (as of nim devel 2678fa6):

import strformat

type Person = tuple[name: string, age:int]
let person: Person = ("Peter", 30)

echo fmt"Tuple person of type {$person.type} = {person}"

---

Rule of thumb:

• Use the $type(FOO) instead of FOO.type.name, as there could be a field literally named name in FOO.
• Refrain from naming a tuple field name.

Given that we understand this confusion between the two "name"s and the $ approach looks better anyways, I am closing this issue.