Skip to content

Table add missing sink #24721

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

Closed
arnetheduck opened this issue Feb 25, 2025 · 8 comments · Fixed by #24724
Closed

Table add missing sink #24721

arnetheduck opened this issue Feb 25, 2025 · 8 comments · Fixed by #24724
Assignees

Comments

@arnetheduck
Copy link
Contributor

Description

Table should not need to copy its key argument during insertion:

import std/tables
type NoCopies = object

proc `=copy`(a: var NoCopies, b: NoCopies) {.error.}

var t: Table[NoCopies, NoCopies]
t[NoCopies()] = NoCopies() # only moves

The same probably holds for a lot of std lib containers, ie the concept applies to all of them.

Nim Version

2.2

Current Output

Error: '=copy' is not available for type <NoCopies>; requires a copy because it's not the last read of 'key'; try to make key a 'sink' parameter; routine: rawInsert

Expected Output


Known Workarounds

No response

Additional Information

No response

@Araq
Copy link
Member

Araq commented Feb 25, 2025

Ping @demotomohiro please work on this.

@ringabout
Copy link
Member

I will take over it since it is similar to #24720 which lacks corresponding lent and sink in the stdlibs

@arnetheduck
Copy link
Contributor Author

Same for toTable

@arnetheduck
Copy link
Contributor Author

import std/tables
type NoCopies = object

proc `=copy`(a: var NoCopies, b: NoCopies) {.error.}

var t = {NoCopies(): NoCopies()}.toTable()

@ringabout
Copy link
Member

ringabout commented Mar 13, 2025

toTable accepts openArray, which is not to be sunk. Because openArray, which is a view type, doesn't own data. But sink requires owning the data so it can destroy the data there. I'm not sure whether to make it work or detect it at the compile time

@arnetheduck
Copy link
Contributor Author

I'm not sure whether to make it work or detect it at the compile time

well, something like openArray[sinkable[T]] would be the way things happen in other languages - ie the openArray should "pass on" the sinkability of its members so that {$1: $2}.toTable can move the two allocated strings into table storage.

@beef331
Copy link
Collaborator

beef331 commented Mar 14, 2025

It could be a breaking change but adding specializations on seq and array would make it sinkable.

@arnetheduck
Copy link
Contributor Author

adding specializations

this makes for a messy language because every time there's something that takes openArray, it would also need these specializations which kind of defeats one of the purposes of openArray..

Araq pushed a commit that referenced this issue Mar 22, 2025
narimiran pushed a commit that referenced this issue Mar 25, 2025
narimiran added a commit that referenced this issue Mar 25, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants