That's a long discussion but I find it missing concrete examples. Let it be more clear on a fake example. Imagine there's a Bag[string, T] data structure implemented with a binary tree, like the following where we have stored some data keyed by the words from "Some people don't read the RFCs":
bag
|
+---------------------+-------------------+
| |
+----------------+--------------+ +---------+-----+
| | | |
+-------+--------+ +------+------+ +--------+ +-------+
| | | | | #5 | | #6 |
+---------+ +----------+ +--------+ +--------+ | "Some" | | "the" |
| #1 | | #2 | | #3 | | #4 | +--------+ +-------+
| "don't" | | "people" | | "read" | | "RFCs" |
+---------+ +----------+ +--------+ +--------+
The index of an item in the Bag is denoted #index while the keys are the string words, and the values are not represented.
Your RFC proposal is to offer a new syntax depending on the type of access:
# Read the value in the "read" node.
let r: T = bag{"read"}
# Update value in the "Some" node.
bag{"Some"} = ...new T data value...
# Read the value of the 2nd node, i.e. the "people" one.
let v: T = bag[2]
# Change the value of the 4th node, i.e. the "RFCs" one.
bag[4] = ...other T value...
# Get the values in nodes 3 to 5, i.e. "Read", "RFCs" and "Some".
let s: seq[T] = bag[3 .. 5]
The proposed {} syntax is used to access data by key in containers while the [] syntax is used to access data by position.
This allows querying the data by index range like the last line shows.
This proposal would require to change the way items are accessed in Table for a transition period.
Is it a good summary of the RFC?
It's a good-ish summary and your range [3..5] is another great example why we might want two operators since one could also do a range of {"RFCs" .. "the"}. The augmented tree actually keeps things like "the number of nodes below a node" (or "to the left") and can do a height-of-tree time search to find a node of a given rank. You don't really need much more than a SortedSeq to really demonstrate the interface issue, as mentioned in the long discussion, though. (If you want a simpler algorithmic mental model.)
Some clarifications. We don't ever need to break how Table is accessed (or seq). We could only do the [] and {} for the new bag/sorted bag thing (which is not yet impled in Nim (I have C impls to port)). I think the extent/impact of this idea was misunderstood because there is so little exposure to unkeyed "search" trees. (I've seen some AVL "rope" libraries, the Python blist, etc., but it's definitely off the beaten path). A lot of words were spilled with me trying to explain that.
Mostly, what I think I am getting pushback on (it's not exactly clear) is providing {}/{}= for Table merely as an "alias" after these impls are all in play. That way {} could mean "associative-ish" while [] could mean positional-ish as a more global convention like the add vs append proc or other things in doc/apis.rst. We could preserve backward compatibility forever. Right now {}= is only used in the json module. The {} for Table is just to make it easier to have the object be either a tree or a table. CritBitTree and maybe something else might also benefit from that kind of operator alias (and might be algorithmically updatable to an instrumented tree, actually...Haven't thought about that).
It's possible push back is more general, like "don't ever use two indexing operators like []/{} for some core thing like a tree/sortedseq!" or "don't ever add an alias for Table.[]!!". I don't mean to speak for anyone.
It's not like this is a huge deal to me (however much I may write). It's a neglected interface detail because few libraries have multiassociative things until late in the syntax game, but we soon will, and Nim's fabulously flexible syntax already supports it. It's more consistent with initializer syntax like {:} and highlights possibly slow associative lookup. I feel like if you like {key:val, ..} at all more than @[(key,val),.. then this kind of move would be welcome.
Tutorials/intros/explainers of the language do have to decide "Do I favor internal consistency/clarity of mentioning {} early or do I favor similarity to other prog.langs". I think that about covers the real questions. Oh, and the alternatives to these are to always use [] but with type constructors inside to distinguish the "access mode".