What does Collection.subscript._read do in Swift 5?

CTMacUser · January 31, 2019, 9:02am

I'm trying out Swift 5 (beta) with Xcode 10.2 beta. The fill-in code when you start a member prototype for a Collection subscript give me:

public subscript(position: Base.Index) -> Base.Element {
    _read {
        return base[position]
    }
}

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?

DevAndArtist · January 31, 2019, 9:20am

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:

github.com

apple/swift/blob/main/docs/OwnershipManifesto.md#generalized-accessors

# Ownership

## Introduction

Adding "ownership" to Swift is a major feature with many benefits
for programmers.  This document is both a "manifesto" and a
"meta-proposal" for ownership: it lays out the basic goals of
the work, describes a general approach for achieving those goals,
and proposes a number of specific changes and features, each of
which will need to be separately discussed in a smaller and more
targeted proposal.  This document is intended to provide a framework
for understanding the contributions of each of those changes.

### Problem statement

The widespread use of copy-on-write value types in Swift has generally
been a success.  It does, however, come with some drawbacks:

* Reference counting and uniqueness testing do impose some overhead.

This file has been truncated. show original

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.

John_McCall · January 31, 2019, 3:57pm

It should not be suggesting _read at this time, and possibly ever.

Sajjon · April 25, 2020, 10:28am

@John_McCall I just got autocompletion suggestion __read using Xcode 11.4 (11E146), FYI.

Glad to share details if it helps

twof · June 30, 2020, 12:32am

I'm still seeing this in Xcode 12

suyashsrijan · June 30, 2020, 1:18am

Please file a bug report on bugs.swift.org.

dabrahams · September 8, 2020, 6:44pm

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?

John_McCall · September 8, 2020, 8:37pm

_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.