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` 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 creati
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
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 mo
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 corre
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 som
Some related discussions: making parameters optional certainly makes many of
the Attrs more informative during compile-time.
### Benefit of `Optional` and Non-Nullable Refs.
For example, in the case of the topi operator `sum(x, axis)`, the true type of
axis is `Optional>`. Making this intenti
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://di
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 ad
