Skip to content

Instantly share code, notes, and snippets.

View agocke's full-sized avatar

Andy Gocke agocke

View GitHub Profile
@agocke
agocke / analysis.md
Last active November 10, 2022 18:41 — forked from missymessa/analysis.md
Sample output from Build Analysis service.

I have to insist on using explicit lifetimes for spec'ing. Both because I think it makes the rules a lot clearer, but also because it separates the safety rules from the language semantics. Let me introduce the description of lifetimes in a series of rules:

  1. All expressions with a storage location (things you can take a ref to) have an implicit, language-defined lifetime. These lifetimes tend to be pretty simple. If you say
void M() {
    int x;
} 

The lifetime of int x is the same as the lifetime of method M. This is true for all structs. For fields of types, if the type is a class then the lifetime is the "global" (heap) lifetime. If it's a field of a struct, it's the lifetime of the containing struct. You can think of lifetimes as being part of the type, so while it looks like the type of x is int, it's really (x, $M), where $M is the lifetime of the method M.

ref struct Lexer
{
private Span<char> _buffer;
private int _loc;
public Lexer(Span<char> buffer)
{
_buffer = buffer;
_loc = 0;
}
public ref struct JsonSerializer
{
private Span<byte> _buffer;
private int _loc; // increments as we write
...
public void WriteToBuffer(string s) => ...; // moves _loc
public Seq SerializeEnumerable(int? count) => new Seq(ref this);