[RUNTIME][IR] Allow non-nullable ObjectRef, introduce Optional<T>. #5314
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
tqchen
changed the title
tqchen
force-pushed
the
optional
branch
4 times, most recently
from
5fa3274
to
4218304
Compare
zhiics
reviewed
Apr 12, 2020
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. Changes in this PR: - Introduce _type_is_nullable attribute to ObjectRef - Introduce Optional<T> - Change String to be non-nullable. - Change the API of function->GetAttr to return Optional<T>
junrushao
reviewed
Apr 13, 2020
zhiics
approved these changes
Apr 13, 2020
|
I'll review Monday morning. |
MarisaKirisame
approved these changes
Apr 13, 2020
|
@MarisaKirisame we don't have to expose optional to python as we can directly use python's Optional for typing. When the normal object typing is used, i believe they are not nullable, the runtime python object themselves are nullable. |
8 tasks
trevor-m
pushed a commit
to trevor-m/tvm
that referenced
this pull request
Apr 16, 2020
…pache#5314) * [RUNTIME] Allow non-nullable ObjectRef, 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<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. Changes in this PR: - Introduce _type_is_nullable attribute to ObjectRef - Introduce Optional<T> - Change String to be non-nullable. - Change the API of function->GetAttr to return Optional<T> * Address review comments * Upgrade all compiler flags to c++14 * Update as per review comment
zhiics
pushed a commit
to neo-ai/tvm
that referenced
this pull request
Apr 17, 2020
…pache#5314) * [RUNTIME] Allow non-nullable ObjectRef, 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<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. Changes in this PR: - Introduce _type_is_nullable attribute to ObjectRef - Introduce Optional<T> - Change String to be non-nullable. - Change the API of function->GetAttr to return Optional<T> * Address review comments * Upgrade all compiler flags to c++14 * Update as per review comment
dpankratz
pushed a commit
to dpankratz/incubator-tvm
that referenced
this pull request
Apr 24, 2020
…pache#5314) * [RUNTIME] Allow non-nullable ObjectRef, 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<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. Changes in this PR: - Introduce _type_is_nullable attribute to ObjectRef - Introduce Optional<T> - Change String to be non-nullable. - Change the API of function->GetAttr to return Optional<T> * Address review comments * Upgrade all compiler flags to c++14 * Update as per review comment
Lunderberg
added a commit
to Lunderberg/tvm
that referenced
this pull request
Oct 27, 2022
This parameter is nullable for cases where the else block isn't present. Previously, it was represented as a `Stmt` holding `nullptr`, because `IfThenElse` (apache#3533) predates the `Optional` utility (apache#5314). This commit updates to use `Optional<Stmt>` instead, and updates all usages of `else_case`.
xinetzone
pushed a commit
to daobook/tvm
that referenced
this pull request
Nov 10, 2022
This parameter is nullable for cases where the else block isn't present. Previously, it was represented as a `Stmt` holding `nullptr`, because `IfThenElse` (apache#3533) predates the `Optional` utility (apache#5314). This commit updates to use `Optional<Stmt>` instead, and updates all usages of `else_case`.
xinetzone
pushed a commit
to daobook/tvm
that referenced
this pull request
Nov 25, 2022
This parameter is nullable for cases where the else block isn't present. Previously, it was represented as a `Stmt` holding `nullptr`, because `IfThenElse` (apache#3533) predates the `Optional` utility (apache#5314). This commit updates to use `Optional<Stmt>` instead, and updates all usages of `else_case`.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
Changes in this PR: