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.
5
Some concepts come to mind (you would need to do some own research for C++/Rust, I only linked a first result):
Lazy<T>: A value that will be computed at a possible later time, but is guaranteed to be there, unlikeOptional.
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.
Future: Value will be computed asynchronously and is often accessed in a reactive way
Examples: Future (Java),Promise (JS)
C++: std::future
- Computed properties
Example: C#
- 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.
2
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.