Allow non-nullable Object and Introduce Optional<T>

We use ObjectRef and their sub-classes extensively throughout our codebase. Each of ObjectRef’s sub-classes are nullable, which means they can hold nullptr as their values.

While in some places we need nullptr as an alternative value. The implicit support for nullptr in all ObjectRef creates additional burdens for the developer to explicitly check defined in many places of the codebase.

Moreover, it is unclear from the API’s intentional point of view whether we want a nullable object or not-null version(many cases we want the later).

Borrowing existing wisdoms from languages like Rust. We propose to introduce non-nullable ObjectRef, and Optional container that represents a nullable variant.

To keep backward compatiblity, we will start by allowing most ObjectRef to be nullable. However, we should start to use Optional as the type in places where we know nullable is a requirement. Gradually, we will move most of the ObjectRef to be non-nullable and use Optional in the nullable cases.

Such explicitness in typing can help reduce the potential problems in our codebase overall.

1 Like

POC https://github.com/apache/incubator-tvm/pull/5314

Some related discussions: making parameters optional certainly makes many of the Attrs more informative during compile-time.

Benefit of Optional<T> and Non-Nullable Refs.

For example, in the case of the topi operator sum(x, axis), the true type of axis is Optional<Array<Integer>>. Making this intention clear would help to make the code more readable. Because we need to explicitly call value() function in Optional<T> to get the underlying type T, it would reminds the developer to do not null check before doing so.

Another example is that in most cases our IR nodes’s fields are expected to be not-null. Making some of the IR refs(Expr, Stmt) not non-nullable will increases the robustness in our codebase via statically type checking.

Engineering Cost for non-nullable ObjectRefs

Non-nullable refs does introduce a bit of engineering overhead. In particular, non-nullable refs may not have a default constructor(the default behavior of nullable refs defaults to nullptr) to let us enjoy more compile time checks. This means we need to introduce the member init constructor for each ObjectNode.

Say PrimExpr is notnullable.

class RangeNode : public Object {
 public:
   PrimExpr min;
   PrimExpr extent;
   // because min/extent does not have default constructor
   // we have to explicitly create such constructors
   RangeNode(PrimExpr min, PrimExpr extent)
     : min(min), extent(extent) {}
   // rest of the code
};

class Range : public ObjectRef {
 public:
   Range make_by_min_extent(PrimExpr min, PrimExpr extent) {
      // old-style no longer works, because there is no default constructor.
      // auto n = make_object<RangeNode>();
      //  n->min = std::move(min);
      //  n->extent = std::move(extent);
      // return Range(n);
      // Need to directly call the constructor of RangeNode to intialize the fields.
      return Range(make_object<RangeNode>(min, extent));
   }
};

Sugars Enabled by Optional

Because Optional<T> overloads operator bool, and comparison operators, it enables certain sugars to reduce the length of the code

// get a value for return null
Optional<String> GetValueOrNull();

void Example() {
   if (auto opt = GetValueOrNull()) {
      // opt contains not-null value
     String value = opt.value();
     // code 
   }
}

Optional<T> can directly compares to T, by checking the optional to be notnull then run the comparison.

void Example(PrimFunc f) {
   if (f->GetAttr<Integer>(key, 0) == 10) {
   }
}

Thank you for bringing this proposal. Overall it looks very nice - it saves us a lot of engineering effort to check nulls, and is a stronger convention that could be adopted in the codebase.

I am more concerned about the upgrading plan. As for now, nullable ObjectRef is still allowed, but some day in the future is behavior will be changed. A clearer timeline will give us a better idea what to upgrade and when to upgrade :slight_smile:

Right now the not-null ObjectRef is opt-in. That means by default an ObjectRef is nullable. We can gradually change the Ref types to not nullable, the steps are:

  • Change macro to TVM_DEFINE_NOTNULLABLE_OBJECT_REF_METHODS,
  • Remove the default constructor(if already defined) that corresponds to nullptr if there is a custom defined one.
  • Fix the compile error
    • For structs that takes the ref as a member, possibly due to unavailable default constructor, change to a new copy constructor
    • For cases that needs nullable version, use Optional

See example change for String https://github.com/apache/incubator-tvm/pull/5314/files#diff-6597547f217e514b638f9548fda1dbcaR528

So hopefully the upgrade will be smooth and incremental instead of a one-time big change. In the meanwhile, we do recommend to directly start using Optional<T> in cases where nullptr behavior is required.

Once we have migrated most of the Ref, we might decide to change the default behavior to opt-out. Which means, by default _type_is_nullable property for the ObjectRef is set to be true.

1 Like

Let’s also attach the task items in this thread :slight_smile:

Is it going to be compatible with std::optional from C++17? It would be nice to just switch to the std version, once we start using C++17.

So far it is specially designed for ObjectRef types, so that we can use nullptr to store the not an option.

The advantage is that the Optional<T> is essentially T during runtime and won’t incur additional storage cost. It is more like a better typing protection in the C++ rather than creating a new wrapper that has an additional nullopt field.

Due to the restrictions of only working with the ObjectRef, it is not compatible with the std::optional, which might need to introduce additional storage to support any types