Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[typetraits] Tuple type name confusion #7976

Closed
kaushalmodi opened this issue Jun 6, 2018 · 5 comments · Fixed by #10071
Closed

[typetraits] Tuple type name confusion #7976

kaushalmodi opened this issue Jun 6, 2018 · 5 comments · Fixed by #10071

Comments

@kaushalmodi
Copy link
Contributor

kaushalmodi commented Jun 6, 2018

Hello,

I don't know how to correctly describe this bug.. see the below examples to understand the issue.

import strformat, typetraits
type Person = tuple[name: string, age: int]
let 
  person1: Person = ("Peter", 30)
  person2 = (name : "Peter", age : 30)
echo fmt"Tuple person1 of type {$person1.type} = {person1}"
echo fmt"Tuple person2 of type {$person2.type} = {person2}"
Tuple person1 of type Person = (name: "Peter", age: 30)
Tuple person2 of type Person = (name: "Peter", age: 30)
                      ^^^^^^ <-- was expecting "tuple[name: string, age: int]" here
import strformat, typetraits
type Person = tuple[name: string, age: int]
let 
  person1 = (name : "Peter", age : 30)
  person2: Person = ("Peter", 30)
echo fmt"Tuple person1 of type {$person1.type} = {person1}"
echo fmt"Tuple person2 of type {$person2.type} = {person2}"
Tuple person1 of type tuple[name: string, age: int] = (name: "Peter", age: 30)
Tuple person2 of type tuple[name: string, age: int] = (name: "Peter", age: 30)
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ <- was expecting "Person" here

As Person is type tuple[name: string, age: int], the type "name" gets stuck to the first type I use to declare the variable.

@Vindaar
Copy link
Contributor

Vindaar commented Jun 6, 2018

It actually seems to be even weirder (at least to me). It's not the order in which you declare the variable, but the order in which you print the names:

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

prints them both as Person, whereas

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

prints them as tuple. But if instead of $ one directly calls name it works just fine:

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

prints the first as Person and the second as tuple as one would expect.

@timotheecour
Copy link
Member

see this comment #8569 (comment)

@kaushalmodi
Copy link
Contributor Author

kaushalmodi commented Jan 2, 2019

Interesting, I just rebuilt Nim devel (a1e268e) and looks like this issue got fixed by a positive side-effect of some commit :D

@timotheecour @Araq If you guys know which commit could have fixed this, please link that commit here for future reference. Thanks to whoever fixed this 👍

timotheecour added a commit to timotheecour/Nim that referenced this issue Jan 2, 2019
timotheecour added a commit to timotheecour/Nim that referenced this issue Jan 2, 2019
timotheecour added a commit to timotheecour/Nim that referenced this issue Jan 2, 2019
timotheecour added a commit to timotheecour/Nim that referenced this issue Jan 2, 2019
@timotheecour
Copy link
Member

@kaushalmodi @Araq I verified that it was as a side effect of my recent PR #10071; not exactly sure why though.
I'm adding a test case so we avoid future regressions (we should always add a test case before closing!)=> see PR #10169

@kaushalmodi
Copy link
Contributor Author

This issue has been fixed for a while; closing it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants