How does it work if I assign a variable with a set of views to an empty interface value? Do I have to have exactly the correct set of views in order to type assert the empty interface value back to the original type? Do the views have to be listed in the same order?

Good questions. I would say that you can type-assert to a view with any subset of the concrete capabilities, with the usual caveat that element types for maps, slices and pointers must be exact. As with interfaces, the first match in a switch wins.

The capabilities in a view are an unordered set, so you could enumerate them in any order.

Another interesting question: what would == mean for two interface{} values with different views of the same object? Arguably it should be consistent with switch and map. Map keys should be unequal because they may have different method sets, which suggests that switch should require an exact match on the capabilities.

One of the things I would like to see from any system like this is support for some form of thread safety analysis (https://clang.llvm.org/docs/ThreadSafetyAnalysis.html). Is there a way to use this syntax to say "this field requires this mutex to be held?" Unfortunately it seems kind of out of scope.

This proposal might be possible to extend to locking invariants, but it would make the specification much more complex. As I see it, one of the advantages of this proposal is that it enforces the capabilities within the Go type system (rather than in an external tool), so extending it to thread-safety analysis would mean that we encode that analysis in the Go spec.

One way to do that might be to add an Escape capability to reference-like types and define a new (safe) Mutex type in terms of that, but then we would have to specify what Escape actually means. With that approach (and assuming generics), the Mutex API might look like:

package sync

type [T] Mutex struct {
	WithLock(func(*T#{Getter,Setter}))
}

whereas atomic would require the Escape capability:

package atomic

func [Ptr] SwapPointer(addr *(Ptr#Escape)#Atomic, new Ptr#Escape) (old Ptr#Escape)

Ptr#Escape applied to an existing view type Ptr would mean “Ptr augmented with Escape”. So, for example, concrete instantiations of SwapPointer might look like:

func SwapPointer[*T] (addr **T#Atomic, new *T) (old *T)

func SwapPointer[*T#Getter] (addr *(*T#{Getter,Escape})#Atomic, new *T#{Getter,Escape}) (old *T#{Getter,Escape})

(I've realized in writing more examples that capabilities should associate loosely rather than tightly: too many parentheses. Updating examples.)

/cc @jaekwon

One thing I dislike about this proposal is that it only provides upper bounds on capabilities, not lower bounds. For example, I cannot express “must be non-nil” as a capability under this formulation, even though it clearly relates to the Setter and Getter capabilities.

[Edit: can too. See below.]

/cc @wora

On further reflection, I think this proposal can express “must be non-nil” constraints: we just have to express them as a positive capability (“can be nil”) rather than a negative constraint (“must be non-nil”)

That suggests another built-in capability, as follows:

Types with a nil zero-value are called nillable. All nillable types have the built-in capability Nil, which allows comparisons with the predeclared identifier nil. nil can be assigned to a variable only if it has both the Setter and Nil capabilities.

When a variable of a nillable type without the Nil capability is initialized (explicitly or implicitly), including as a function argument, struct field, or array or slice element, the compiler must be able to verify statically that the value is not nil. (TODO: propose a precise algorithm.)

• Slice elements with indices ≥ len are treated as uninititalized. If a slice with elements of nillable type that lack the Nil capability is resliced past its length, a run-time panic occurs, analogous to reslicing any slice past its capacity. (See Proposal: use a value other than nil for uninitialized interfaces #21538 (comment) for further discussion.)
• The result of a channel receive or map index expression always has the Nil capability if the element type is nillable, even if the element type itself lacks the Nil capability.
• A type-assertion to a nillable type without the Nil capability fails if the underlying value is nil. (That is, the type does not match.)
• Each named result parameter without the Nil capability must be non-nil as of the first read or write of the parameter on each path through the function, including implicit writes in return statements.

The operator sequence &* panics if its pointer argument is nil, so it can be used as a handy way to assert non-nilness to the compiler. If we adopt this proposal, we should consider defining &* as an explicit “panic if nil” operator for all nillable types.

I believe this proposal also subsumes #23764. If a struct type has a field without the Getter property, that struct cannot be copied: we would have to read the field in order to copy it.

I do think the syntax for #Getter and #Setter is a bit verbose. If we like the general idea, I can try to find a cleaner shorthand for the built-in constraints.

can only access methods and fields that are not associated with a Restriction.

1. What's a Restriction? Do you mean Capability?

2. Should there be an automatic conversion from string to ([]byte)#Getter?

3. I tried to write the signature for a generalized strings.Trim. The best I could come up with is

func [T#Getter] Trim(s ([]T)#Getter, xs ([]T)#Getter) ([]T)#Getter 

But this is too restrictive; it says the return type has only Getter, but I want it to have all the Capabilities of the first argument. I can't write the return value as simply []T, because that would mean it has no capabilities attached. In your comment on locking invariants you say "V#C applied to an existing view type V would mean 'V augmented with C'." Does that apply here? If so, how do I indicate the I want to augment the first argument's capabilities, and not the second's?

I think you'll need generic capability parameters:

func [T#Getter, C] Trim(s ([]T)#{C, Getter}, xs ([]T)#Getter) ([]T)#{C, Getter}

4. Here is a generic Clone for pointers:

func [T] Clone(x *T) *T {
    y := *x
    return &y
}

How can I express that neither the argument nor the return value have Nil? You mention &* as a way to express non-nilness, but how can I use that in a signature?

Maybe T#-C means "T without C"?

func [T] Clone(x (*T)#-Nil) (*T)#-Nil {
    y := *x
    return &y
}

5. I'm writing a cache. I want to make sure callers of my Get method get deeply read-only views of my values, so users can't corrupt them. How can I express this? Get(Key) Value#Getter doesn't work, because the values may contain fields that are gettable, but can themselves be modified.

What's a Restriction? Do you mean Capability?

Yep, leftover from an earlier draft. Fixed.

Should there be an automatic conversion from string to ([]byte)#Getter?

That's not obvious to me one way or the other, especially given the need for capability parametricity. (That is: it may be that the need for parametricity implies that pretty much all string-or-[]byte functions are already generic to begin with.)

Are there any other languages with a facility similar to this?

Typically in programming language the term "capability" refers to the right to perform some operation. These attributes seem almost like the reverse of that: rather than granting certain rights, they remove them. "Capability" may not be the best name here.

The capability syntax is very general but it seems that specific capabilities have specific meanings implemented by the compiler. Are there meanings for capabilities other than those implemented by the compiler?

This seems like an experimental language feature with potentially far reaching consequences, not an established, proven mechanism. As a general rule, Go has avoided adding features that are not well understood.

Are there any other languages with a facility similar to this?

Some of it is like Hermes typestates. Unfortunately, the Hermes book doesn't seem to be available online. From my copy, you could define your own typestates that the compiler would semi-automatically propagate for you, and there were some built-in ones with special meanings.

"Capability" may not be the best name here.

It actually resonates with me: a capability is a reference to a value along with permissions on how you can use it. So actually what Bryan calls a View is a capability (or the type of a capability): *Buffer#Reader is a pointer to a buffer with the ability to read from it. It's just that it defaults open: the absence of #Foo on a type means you can do anything.

Can you provide an example of subsuming #23161? Trying to understand.

1. I do agree that it would be nice to be able to restrict what methods you can call on an interface.
2. I agree with @jba and @ianlancetaylor that the reserved keyword should not be called a "Capability". To me, capability == (dis)ability, and "Object Capabilities" is the study/practice/engineering of capability/access specification/control in the context of a given programming language. But I'm still learning about this so...
3. This gives me a related idea...

A Golang "Interface" is something that can be converted at runtime to a concrete type. What if we just declare a new type called a "Restriction", which is much like an Interface, except it cannot be converted back to an interface or any other type (besides a more restrictive type)?

type FooInterface interface {
    A()
    B()
}
type BarRestriction restriction {
    B()
}
type fooStruct struct {}
func (_ fooStruct) A() {}
func (_ fooStruct) B() {}
func (_ fooStruct) C() {}

func main() {
    f := fooStruct{}
    var fi FooInterface = f
    fi.(fooStruct).C() // FooInterface doesn't include C but we can convert.
    var br BarRestriction = f // OK
    var br BarRestriction = fi // OK
    var br BarRestriction = &fi // Pointers to interfaces don't implement restrictions.
    var fi2 FooInterface = br // NOT OK
    br.A() // NOT OK
    br.B() // OK
    br.C() // NOT OK
    br.(FooInterface).A() // NOT OK
    br.(fooStruct).A() // NOT OK
    br.(fooStruct).A() // NOT OK
}

This just saves us from declaring another structure to hold an unexposed reference to a reference object, and copying the method signatures that we want to expose from the referenced object.

type Foo struct {
    bar Bar
}
func (a Foo) A() { a.bar.A() } // THIS IS...
func (a Foo) B() { a.bar.B() } // ...TEDIOUS...
type Bar struct { ... }
func (b Bar) A() {}
func (b Bar) B() {}
func (b Bar) C() {} // HIDE ME!

Are there any other languages with a facility similar to this?

HP's Emily added capability verification to OCaml, but as a subtraction from the language rather than an addition. OCaml already has at least two other features that provide a similar sort of capability restriction: row polymorphism and object subtyping. With row polymorphism, capabilities are encoded as record fields (in Go, struct fields), and functions can accept input records with arbitrary additional fields (which the function cannot access). With object subtyping, capabilities are encoded as methods on an object type, and any object with at least those methods can be coerced to (but not from!) that type.

Mezzo represents static read and write permissions as types (as in this proposal), but also adds a consume keyword that allows a function to revoke the caller's permissions after the call, allowing for constraints such as “called only once”. However, it isn't obvious to me whether it allows for user-defined permissions: the Mezzo literature focuses on controlling aliasing and mutability.

Microsoft's Koka has user-defined effect types. Its effects track capabilities at the level of “heaps” rather than variables. (Heap- or region-level effects are typical of “effect systems”, which are mainly oriented toward adding imperative features to functional languages.)

Wyvern (described in this paper) checks capabilities statically, but at the level of modules rather than variables.

Wikipedia has a list of other languages that implement object capabilities. Admittedly, that list is mostly research languages, and many of those languages use a dynamic rather than a static form of these capabilities. (For example, the E programming language, from which many of the others derive, uses pattern matching and Smalltalk-style dynamic dispatch to construct facets with restricted capabilities. You can think of E facets as the dynamic equivalent of the static “views” in this proposal.)

Several other languages have build-in keywords that resemble the various built-in capabilities in this proposal, but do not allow for user-defined capabilities. (For example, consider mut in Rust or iso in Pony.)

The Nil capability described above does closely resemble Hermes typestates (thanks, @jba!).

For those with ACM or IEEE library access, there are a few shorter Hermes papers available:
https://dl.acm.org/citation.cfm?id=142148
https://ieeexplore.ieee.org/document/138054/

These attributes seem almost like the reverse of that: rather than granting certain rights, they remove them. "Capability" may not be the best name here.

There are two related concepts here: “capabilities” and “views”. A “capability” grants a (positive) permission for some method, field, or variable; a “view” restricts a variable (generally a function argument) to a particular subset of its capabilities.

(I'm not attached to the naming, but I couldn't think of anything more appropriate. Please do suggest alternatives!)

Are there meanings for capabilities other than those implemented by the compiler?

Yes: since methods and fields can be restricted to capabilities, they can have any meaning that can be expressed as a method set. That is both a strength and a weakness of this proposal: a strength in that it allows for user-defined behavior, but a weakness in that it partially overlaps with interfaces. (Views are not interfaces, however: methods removed by a view cannot be restored by a type assertion.)

For example, see the #Client and #Server capabilities in http.Request in the proposal.

@jaekwon The #&Getter view (a VarView) functions similarly to the const keyword from #23161:

// Read-only reference to an unrestricted slice.
var myArray #&Getter []byte = make([]byte, 10)

// Read-only struct.
var myStruct #&Getter = MyStruct{...}

// Read-only pointer to a mutable struct.
var myStructP #&Getter = &MyStruct{...}

// Read-only interface variable.
var myStruct #&Getter MyInterface = MyStruct{...}
var myStructP #&Getter MyInterface = &MyStruct{...}

// Read-only function variable
var myFunc #&Getter = func(){...}

(@jba, just so you know, I'm not ignoring your questions about Trim and Clone: they're subtle and interesting points that require more thought.)

On further consideration, I've decided to withdraw this proposal.

It was motivated in part by Ian's question in #22876 (comment):

Why put one promise into the language but not the other?

However, in order to make the result general I've had to sacrifice both conciseness and uniformity: each built-in capability and shorthand syntax would make the language less orthogonal, and without them the proposal is both too weak and too verbose: it addresses a broad set of problems but none cleanly. That's the opposite of the Go philosophy.

I do think it's an interesting framework for thinking about other constraints we may want to add, but it's not a good fit itself.