I'm looking for prior art related to following patent:


A language extension that advances safety in system programming by specifying a lifetime of a reference that represents a resource. In accordance with the language extension, the lifetime references a particular scope in a manner that the compiler generates computer-executable instructions that enforce the lifetime of the reference to be a function of (e.g., no longer than) the lifetime of the particular scope. Accordingly, the resource lifetime may be specified in advance to have a particular scope. This helps in performing resource management as typical managed language programs can allow resources to exist indefinitely. Furthermore, because the resources have a defined finite lifetime, they might be more conveniently allocated on a stack, instead of on a heap, for much more efficient processing.



  1. A computer-implemented method for declaring that a particular reference in a software program has a finite lifetime, the method comprising:

    an act of accessing a software program under construction that includes a reference that defines a resource; and

    an act of annotating a reference of the software program to be associated with a particular scope having a finite lifetime, wherein the annotation is structured such that the compiler enforces a lifetime of the reference to be a function of the lifetime of the particular scope.

5 Answers 5


The D programming language has scope classes, shown here in the "Scope Classes" section. (quoted for convenience)

Scope Classes

A scope class is a class with the scope attribute, as in:

scope class Foo { ... }

The scope characteristic is inherited, so if any classes derived from a scope class are also scope.

An scope class reference can only appear as a function local variable. It must be declared as being scope:

scope class Foo { ... }

void func() {
  Foo f;    // error, reference to scope class must be scope
  scope Foo g = new Foo(); // correct

When an scope class reference goes out of scope, the destructor (if any) for it is automatically called. This holds true even if the scope was exited via a thrown exception.

Oldest history I can find quickly for this is in the earliest commit of the Dlang.org website on Github, dated 9 March 2008

Additionally, the Rust programming language has explicit lifetimes for pointer variables.

  • I don't understand what you're referring to by the passage of time. Rust's reference lifetimes correspond to an object's scope, and prevent the reference from outliving the live scope. The Rust compiler infers most of the lifetimes, but it is possible and sometimes necessary to annotate references with a lifetime. It's exactly what the patent's abstract is referring to, as it's nowhere near a new concept. Cyclone is a much earlier example of prior art.
    – strcat
    Aug 26, 2014 at 23:15
  • 1
    I added claim 1 and posted a comment with erroneous information. That is what strcat references above. I deleted the technically way off-base comment.
    – George White
    Aug 27, 2014 at 0:28
  • Can you scope classes without the scope attribute in D? I haven't read the whole patent but it seems to me the claim can. @strcat can you post an example? I had quick look at Rust and to me it seems the programmer can be explicit about stack vs heap allocation.
    – Max
    Aug 27, 2014 at 7:18
  • The patent isn't about ownership or scope-based destructors. It covers tracking the lifetimes of non-owning references to those resources / stack allocations with region typing. Just because something has the word scope in it or has to do with lifetimes doesn't mean it's the same thing as they're describing here. It doesn't have to do with being explicit about stack vs. heap allocation either.
    – strcat
    Aug 27, 2014 at 15:41

Prior art:

GNU's GCC cleanup extension for C, http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization#GCC_.22cleanup.22_extension_for_C

Google's Go language, defer statement.

Any C++ code using RAII that is then compiled through CFront.

Any C or C++ code using a macro to limit lifetime of anything.

Any code generator in any language that generates RAII.

The time claim is spurious and satisfied by practically all RAII implementations.

There is no innovation here. The concept itself is contained within http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization#CITEREFStroustrup1994.

The claims of this patent are liken to the claiming of a patent on a wooden wheel spoke in the case it is produced by a lathe rather than hand carved.

  • The patent is different than just plain old destructors. It refers to tracking the lifetimes of references to those objects with destructors (or just objects on a stack frame) in order to prevent reference/iterator invalidation without a garbage collector. It's an attempt to patent the application of region typing used in Cyclone (2006) and later Rust (2010). Both of those languages arrived at a similar implementation independently, which demonstrates that it's a pretty obvious application of the underlying type theory.
    – strcat
    Aug 27, 2014 at 6:21
  • 1
    It is but a simple extension, a one step indirection, easily done via macros which are a form of language extension. All of it derives simply from the RAII concept and is conceptually no different from the relationship between fibonacci sequence N and N+1. A box in a box in a box is still a box.
    – Brian
    Aug 27, 2014 at 6:48
  • @strcat: That's entirely not true. Plain old destructors implement tracking lifetimes of references to objects. See smart pointers in C++. Hell, the entire purpose of destructors is to track the lifetimes of references to things that need cleaning up. std::string is tracking the lifetime of references to a character array. Even SEH on Windows tracks the lifetime of references to exception handlers.
    – Puppy
    Aug 27, 2014 at 11:33
  • @Puppy: It's not referring to smart pointers, which rely on scope-based destruction. It's referring to region typing on non-owning references to prevent reference invalidation, including references to objects on the stack without any destructor. The use of scope-based destructors is a side issue, not part of the claims in the patent.
    – strcat
    Aug 27, 2014 at 15:39
  • 1
    Er, the compiler definitely tracks the lifetime of all stack-allocated objects. Destructors tie the lifetime of heap-allocated objects to the lifetime of stack-allocated objects- which are often references, as in the case of smart pointers, containers, whatever- so effectively, the compiler tracks the lifetime of heap-allocated objects.
    – Puppy
    Aug 28, 2014 at 13:38

Prior art:

Microsoft's Stack Semantics for Reference types, first reference in VS2005 http://msdn.microsoft.com/en-us/library/ms177191(v=vs.80).aspx

When you create an instance of a reference type using stack semantics, the compiler does internally create the instance on the garbage collected heap (using gcnew).
When the signature or return type of a function includes an instance of a by-value reference type, the function will be marked in the metadata as requiring special handling (with modreq). This special handling is currently only provided by Visual C++ clients; other languages do not currently support consuming functions or data that use reference types created with stack semantics.


Rust uses a lifetime system based on region typing to statically verify the lifetimes of references. It prevents reference / iterator invalidation at compile-time without any overhead - no reference counting required. Most of this is dealt with by the compiler's lifetime inference, but non-trivial function signatures need to be marked with named lifetimes - as mentioned in this patent.


A lot of the answers mention destructors / smart pointers, but I think that's off the mark. Rust does have types with destructors / move semantics (affine types) too, but it's a different language feature than lifetimes. Destructors manage the lifetime of a specific owned object by tying it to a scope and don't need any of this fancy lifetime analysis.

For example, Rust's Rc<T> type has a destructor and thus has move semantics, so ownership is tied to a variable but can be transferred elsewhere. A reference count is done by calling clone to create a new owner, and there is a concept of a non-owning Weak<T> reference. None of that falls under this patent - what does is the ability to take a lightweight reference into the Rc<T> and then pass that to functions only aware of &T and not Rc - without any memory unsafety, even in cases where references deeper inside are returned.


I might be wrong, but I think there is prior art from Microsoft Research itself in the form of the Vault programming language


According to the only document I can find now

In short, the benefit of giving an object a tracked type is that the Vault type checker can trace the availability and state of that object throughout the program’s text.

(the paper also cites the "Typestate" paper which was also the original inspiration for Rust, IIRC)

  • Rust doesn't actually use typestate anymore but rather relies on affine types (destructors / move semantics) and region typing for static verification of reference lifetimes. The usage of region typing in Rust is exactly like this patent - including the ability to annotate named lifetimes when it can't be inferred or just for clarity.
    – strcat
    Aug 29, 2014 at 2:32
  • thanks, that is what I meant with "original inspiration", but I guess it was poorly worded.
    – riffraff
    Aug 29, 2014 at 14:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .