You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@tvm.apache.org by tqchen via TVM Discuss <no...@discuss.tvm.ai> on 2020/04/12 22:18:12 UTC

[TVM Discuss] [Development/RFC] Allow non-nullable Object and Introduce Optional


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<T> 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<T> 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<T> in the nullable cases.

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





---
[Visit Topic](https://discuss.tvm.ai/t/allow-non-nullable-object-and-introduce-optional-t/6337/1) to respond.

You are receiving this because you enabled mailing list mode.

To unsubscribe from these emails, [click here](https://discuss.tvm.ai/email/unsubscribe/9b05ca265d2cff81d9cff2684d56dfa3d341b3f8a1d1f12cd6fdc2904b0c7ba6).

[TVM Discuss] [Development/RFC] Allow non-nullable Object and Introduce Optional

Posted by tqchen via TVM Discuss <no...@discuss.tvm.ai>.


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





---
[Visit Topic](https://discuss.tvm.ai/t/allow-non-nullable-object-and-introduce-optional-t/6337/8) to respond.

You are receiving this because you enabled mailing list mode.

To unsubscribe from these emails, [click here](https://discuss.tvm.ai/email/unsubscribe/368c05c7982f245df848855869af7489bdec5b098891f974003a8a88ced48a8b).

[TVM Discuss] [Development/RFC] Allow non-nullable Object and Introduce Optional

Posted by Krzysztof Parzyszek via TVM Discuss <no...@discuss.tvm.ai>.


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.





---
[Visit Topic](https://discuss.tvm.ai/t/allow-non-nullable-object-and-introduce-optional-t/6337/7) to respond.

You are receiving this because you enabled mailing list mode.

To unsubscribe from these emails, [click here](https://discuss.tvm.ai/email/unsubscribe/58a91324c5eb759ea12a36af3066b12c213aa29c601eb23127e49fb0e0e4ecf9).

[TVM Discuss] [Development/RFC] Allow non-nullable Object and Introduce Optional

Posted by tqchen via TVM Discuss <no...@discuss.tvm.ai>.


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.





---
[Visit Topic](https://discuss.tvm.ai/t/allow-non-nullable-object-and-introduce-optional-t/6337/5) to respond.

You are receiving this because you enabled mailing list mode.

To unsubscribe from these emails, [click here](https://discuss.tvm.ai/email/unsubscribe/dc39157ed3b8a213b390492f717497f0dbeaedf624875447387f0fafe4621f51).

[TVM Discuss] [Development/RFC] Allow non-nullable Object and Introduce Optional

Posted by Junru Shao via TVM Discuss <no...@discuss.tvm.ai>.


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 :-)





---
[Visit Topic](https://discuss.tvm.ai/t/allow-non-nullable-object-and-introduce-optional-t/6337/4) to respond.

You are receiving this because you enabled mailing list mode.

To unsubscribe from these emails, [click here](https://discuss.tvm.ai/email/unsubscribe/416ffd8c53a4c45d2afa97211ad6aa3f6bed256a9d54dc522a342596fa134f0b).

[TVM Discuss] [Development/RFC] Allow non-nullable Object and Introduce Optional

Posted by tqchen via TVM Discuss <no...@discuss.tvm.ai>.


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.
```c++
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.
```c++
void Example(PrimFunc f) {
   if (f->GetAttr<Integer>(key, 0) == 10) {
   }
}
```





---
[Visit Topic](https://discuss.tvm.ai/t/allow-non-nullable-object-and-introduce-optional-t/6337/3) to respond.

You are receiving this because you enabled mailing list mode.

To unsubscribe from these emails, [click here](https://discuss.tvm.ai/email/unsubscribe/962bea9fbbb0469a610b167963f5b7ac9ba053faef74f1c754e210b47df29f7b).

[TVM Discuss] [Development/RFC] Allow non-nullable Object and Introduce Optional

Posted by tqchen via TVM Discuss <no...@discuss.tvm.ai>.


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





---
[Visit Topic](https://discuss.tvm.ai/t/allow-non-nullable-object-and-introduce-optional-t/6337/2) to respond.

You are receiving this because you enabled mailing list mode.

To unsubscribe from these emails, [click here](https://discuss.tvm.ai/email/unsubscribe/5ab7744f4b3114a77e26102d240d350ebd75fa5db36a2a8e499ad24d3fee8192).

[TVM Discuss] [Development/RFC] Allow non-nullable Object and Introduce Optional

Posted by Junru Shao via TVM Discuss <no...@discuss.tvm.ai>.


Let's also attach the task items in this thread :slight_smile:
 
https://github.com/apache/incubator-tvm/issues/5318





---
[Visit Topic](https://discuss.tvm.ai/t/allow-non-nullable-object-and-introduce-optional-t/6337/6) to respond.

You are receiving this because you enabled mailing list mode.

To unsubscribe from these emails, [click here](https://discuss.tvm.ai/email/unsubscribe/3e61df8f1e5baaa03cacf90d57cf6f905ec3cca30dcfd0eea241c7eee839adea).