Syntax:
str: "+STR+"
This event represents the start of a YAML stream. A stream contains zero or more DOC nodes.
I hereby claim:
To claim this, I am signing this object:
This means that users with an account that Candid recognizes
can access the controller as long as they have appropriate
permissions granted. Note that Candid usernames are given
an @external
suffix to distinguish them from controller-local usernames.
Note that identity-url can only be set at bootstrap time and cannot be changed later.
The allow-model-access=true
setting allows users to access models
Roger Peppe 2018/08/30
Here are a few thoughts after looking through the generics document. In general, I really like it. In particular I like the fact that it admits general operations on generic types through an intuitive contract specification that looks just like regular Go.
Roger Peppe, 2018-09-01
One common response to the new generics design has been that contracts seem a bit too much like interfaces but not the same.
They are indeed very similar if you squint a little. Consider these two definitions:
type IReader interface {
Read([]byte)(int, error)
Roger Peppe 2018-09-03
[Edit 2018-09-11 Reworked following feedback from @jba]
In his Go generics feedback document, Dominic Honnef writes "Contracts are nice, but where is the operator overloading?". In this document, I set down some thoughts about how operator overloading might be added to Go within the context of the new generics design, layered on top of the current design.
The central part would be a new package in the standard library. This package would hook a type-parameterized type up to chosen Go operators. The Go compiler would know how to rewrite operator syntax into method call syntax on associated interface methods. How that's done is implementation-defined, and the API itself is defined by a package, but contracts supply a way of reasoning about available operators without defining the mapping between operators and method names.
The compiler would be responsible for making sure exist
From the design document:
Generic functions, rather than generic types, can probably be compiled using an interface-based approach. That will optimize compile time, in that the package is only compiled once, but there will be some run-time cost.
Generic types may most naturally be compiled multiple times for each
In my previous post, I talked about some of the underlying runtime concepts behind generics in Go.
Here I'll go a bit deeper into how we might, in principle, be able to compile a generic function once for many instantiated types.
Roger Peppe, 2018-09-05
Most of the discussion about the new Go contracts proposal has been centred around hypothetical or small-scale examples. As Go is a language that's designed for programming in the large, I thought it might be interesting to see how contracts fitted with a more real-world example.
Roger Peppe, 2018-09-05
In my previous post, I talked about an issue with a real world use case for contracts - the fact that all type parameters must be mentioned every time a contract is used in a definition. In this post, I introduce an idea for a possible way to fix this.
The most important feature of contracts, in my view,