Breaking change or bug re: tuple unpacking?

[michaelsbradleyjr]

Description

The following compiles/runs in Nim 2.0.0 and earlier versions

type Foo = object
  a: int
  b: int

proc foo(): Foo =
  (result.a, result.b) = (1, 2, 3, 4)

echo foo() # => (a: 1, b: 2)

With the devel branch (installed via choosenim devel --latest) there is a compile-time error

Error: tuple with 2 elements expected, but got '(int, int, int, int)' with 4 elements

Is there an upcoming breaking change re: unpacking or is this a bug?

Nim Version

Nim Compiler Version 2.1.1 [MacOSX: amd64]
Compiled at 2023-12-07
Copyright (c) 2006-2023 by Andreas Rumpf

git hash: e1a0ff1
active boot switches: -d:release

Current Output

Error: tuple with 2 elements expected, but got '(int, int, int, int)' with 4 elements

Expected Output

(a: 1, b: 2)

Possible Solution

Unknown

Additional Information

Someone was asking in the community Discord about nim-package-directory failing to compile with Nim v2 — nim c package_directory.nim per readme. There are some unrelated compile-time errors when 2.0.0 is used but I came across this issue when trying it with current devel.

The problem relates to code in one of the dependencies of nim-package-directory: https://github.com/FedericoCeratto/nim-morelogging/blob/ea61e0e8f49db122cb12c263ba05313a29aeea81/morelogging.nim#L199

[Araq]

It was never supposed to compile.

[metagn]

#22537, the old behavior is hard to justify, you can discard the unused parts of the tuple with _ now but this will not work on older versions, safest to just:

let longTuple = foo()
let a = longTuple[0]
let b = longTuple[1]

[michaelsbradleyjr]

the old behavior is hard to justify

Agreed, and I didn't realize it "works" until investigating compile-time errors with nim-package-directory.

Still, it works in every stable release from 1.0.0 to 2.0.0 (inclusive). Maybe there won't be too many apps and libs affected when the change lands in a stable 2.x.x, but a heads-up in the changelog is probably in order.