Where the "return base[position]" is the code I added. I got an error on that line: Cannot subscript a value of type 'Base' with an index of type 'Base.Index'. I got rid of that code and put the return statement in directly, which still seems to be an implicit get.
What is the difference between get and _read? Why are the requirements for _read different? Does it have to do with a modify tag I occasionally see in the library code?
I don't know if this is still up-to-date, as in this thread John McCall and others mentioned that __shared is slightly different than originally described in the manifesto, but the idea behind read is summed up there nicely:
Since read is not officially proposed yet, it's still prefixed with an underscore.
So instead of return you must yield, but I don't know if it's available in the beta or maybe as _yield, which is also not officially proposed yet.
Hey, John, I just realized that I've been assuming you meant that _read was vestigial and wasn't really a thing distinct from get. Can you clarify whether it has any distinct meaning and if so, what that meaning is?
_read is not vestigial or equivalent to get; it's a coroutine-style accessor, like _modify, which can directly yield a borrowed ("+0") reference to a stored value, the same way that _modify can directly yield an inout reference to mutable storage. Among other things, that means it's capable of exposing an existing value of uncopyable type, which get can't do. That's why Collection's subscript uses a _read instead of a get.
The reasons _read shouldn't be exposed in completion / code-template results are that (1) it's an experts' feature that programmers shouldn't be randomly exposed to and (2) it's not yet officially supported.