dnrops
/
rfcs
mirror of https://github.com/rust-lang/rfcs.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

unresolved question: pick a different term?

This commit is contained in:
Ralf Jung 2024-01-26 15:37:44 +01:00
parent 8914ac77b1
commit 94918b9733
1 changed files with 4 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
text/0000-rust-has-provenance.md
View File

@ -305,6 +305,10 @@ This is deliberate; the RFC discussion should not attempt to delve into those de
The appropriate standard library API functions to let programmers correctly work with provenance (strict provenance APIs) are not yet finalized; their exact shape can be left to T-libs-api in collaboration with T-opsem. The appropriate standard library API functions to let programmers correctly work with provenance (strict provenance APIs) are not yet finalized; their exact shape can be left to T-libs-api in collaboration with T-opsem.
There might be a better name than "provenance".
But (for reasons discussed [above](#descriptive-vs-prescriptive-provenance)), it's not an entirely bad term either.
Ultimately, the biggest hurdle is the concept itself, not its name.
# Future possibilities # Future possibilities
[future-possibilities]: #future-possibilities [future-possibilities]: #future-possibilities