Semantically, C++ std::optional, Rust Option<T>, and other optional/nullable types represent a value that can be present or absent: you have to handle both cases, or you can opt-in to crash.

Is there utility in a type that represents a value that doesn't exist yet, but needs to later on in execution? Or does such a thing exist? Example use case: an offset in AST node that needs to be calculated in a later pass.

  • Which language are you asking about? I think what you're thinking of is something like a OnceCell
    – Alexander
    Sep 14 at 3:55
  • Wanted to know which if any languages have something like this.
    – JJW
    Sep 14 at 4:01
  • I think you're going to need to clarify your question a bit, since after all, what's stopping you from defining this type yourself in any language? But in anycase, there's one example, in Rust.
    – Alexander
    Sep 14 at 4:08
  • "but needs to exist later on". Do you mean "but is guaranteed to exist later on" perhaps? Worded as it is I am like "so, whatever alternative to null values you are asking for, at some point you will have to check for the value to exist after all". Sep 14 at 6:59
  • Future<T>, Promise<T>, Lazy<T> and plenty of other "wrappers" exist. You could roll your own, it just needs to be "poll-able" or "listen-able" when the actual value is ready. Heck, a closure can be passed around as "compute-able when needed" kind of value.
    – S.D.
    Sep 14 at 7:51

3 Answers 3


Some concepts come to mind (you would need to do some own research for C++/Rust, I only linked a first result):

  1. Lazy<T>: A value that will be computed at a possible later time, but is guaranteed to be there, unlike Optional.

Examples: Lazy (kotlin), lazy (swift)

Similar would be lateinit variables in those languages, which does not compute on-demand, but "guarantees" the property will be set before it is accessed.

C++: Found this on SO.

  1. Future: Value will be computed asynchronously and is often accessed in a reactive way

Examples: Future (Java),Promise (JS)

C++: std::future

  1. Computed properties

Example: C#

  1. Supplier/Functions as a way to access calculated values.

Example: Supplier (Java)

In general, there is nothing stopping you from providing a function or initializer as a wrapper to some property. See also the other answer.


Yes, sort of. It is part of almost any major programming language: it is called a first-class function.

Instead of passing a specific value v, one passes a function f around which can calculate v on demand, at the point in time when it is required. It is basically the core concept behind functional programming.

There are several other concepts based on this: objects (in OO) carry data plus functions, they can be passed around and used just like forementioned standalone functions. Generator functions (a.k.a. iterators) allow the generation of iterable sets of values on demand, instead of precalculating some array.

Of course, for things like your "offset in an AST" example, often the most simple approach is to use some nullable or optional type as a placeholder for the values which have to be calculated later. One could surely make use of functional placeholders for such offsets, or model it by using a specific object Offset for it, but this bears a certain risk of making things more complicated than necessary.

  • If we look at it this way, calculated properties in classic OO would also fit the bill. Sep 14 at 5:10
  • @MartinMaat: indeed, any member function of an object can be used that way.See my edit.
    – Doc Brown
    Sep 14 at 6:47

There is a range of possibilities, covering the spectrum from lenient to strict.

You did not explicitly state whether the value can be computed lazily when a client needs it, or is computed in a later pass over the data (your example sounds a bit like that). Depending on this, the approaches could be a bit different.

One is to simply use the optional type, and rely on documentation to ensure that developers use the attribute as intended. This would work in both scenarios.

An alternative would be to use a type that can be computed and set once and cannot be changed later. I'm not sure whether the Once<> type would fit the bill, though.

One possibility that comes to mind with strict typing and functional design would be to have separate types for the AST nodes, one without and one with position information. If it is decidable which parts of your code work with the AST before or after the position-determining pass, you can use these types appropriately, so the type checker would catch any attempts to access the attribute before it is available. The position-determining pass would then not be an operation that fills in position information in an existing AST, but a function transforming a positionless AST into one with positions.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.