Variable Type Hinting

Lazlo Bonin (Lead Developer) 4 years ago updated by Guirie 3 weeks ago 19 4 duplicates

Variables in Bolt are not strongly typed, meaning they can change type during runtime.

This is also why many users think their inspector is bugged because their type reverts to (Null) when no value is assigned. This is not actually a bug, and will not cause any issue, but it is counter intuitive to new users. 

To alleviate that, the user-defined type of the variable should be stored somewhere as a "type-hint". This way, the inspector would never revert to null, even if the value is null. Additionally, a warning could be shown if the variable gets assigned a value during runtime that does not respect the hinted type. 

In-depth technical explanation

Why does the type get reset at the moment? 

Some types are called reference types and support null as a value, for example strings, game objects, or any class. Other types are called value types and do not support null, for example numbers, booleans, or any struct. 

Bolt variables store two things: the name of the variable and its value, because it's the only things Bolt needs to know to be able to get and set this variable during runtime.

When you create a variable of a value type, Bolt can deduce the type of the variable by looking at its value. For example, when it sees that the value is "true", it knows that the type is "boolean". When it sees that a value is "3.25", it knows that the type is "float". Because it can deduce the type, it can show you the right inspector for it in the variables window.

When you create a variable of a reference type and give it a null value (default for strings and Unity objects), Bolt cannot deduce the type. When Bolt sees a "null" value, it doesn't know whether that's a "null string" or a "null game object", because both of these are actually the exact same thing at the CIL level. This is why it cannot show you the right inspector and reverts its type dropdown to "(Null)" after you close the variables window.

This suggestion would save the preferred type alongside the value just to be able to display the right inspector. This would have no hard-limiting effect (you could still change the type of the variable at runtime), but it would be less confusing for new users.

Bolt Version:
Unity Version:
Scripting Backend:
.NET Version (API Compatibility Level):

Duplicates 4

Not a Bug

Hi WoodenDragon,

This is not a bug. Variables are not strongly typed, meaning that a null game object is the same as a null string, for example. When you don't specify a value, Bolt doesn't remember the type because it doesn't need to.

I have the same issue except I first used Transform, what's weird is I also tried switching that variable to a different type (Such as string). And it still reverts back to (Null)

Yes it also happens to transform. Idk about other variable types but many of them just go null.

Let's say that it is intentional then how do Bolt or the program will know what value I'm going to use in graph if the main value in variable tab is null? You saied it works then there should be a practical explanation. 

The program will use "null" as a value. "null" doesn't have a type.

Yeah i get that but how it will know that its the null of gameobject variable or string variable because according to you it can't figure that out unless i add some value to it?

Right now it won't know, and it never needs to know. The "null of a game object" is the exact same thing as the "null of a string".

lazlo i was thinking that this null is creating lots of confuses to many people. I was thinking how about you do an update on it so next time it won't show null so people don't keep questioning about it or you can do something totally different to cure this confusions on later versions.

Sanket, he is doing something. It's right in the original post at the top and is planned. 

Oh sorry i missed it.

I was also confused about this at first... mainly because it always reverted to Null when I clicked Play, but also I remembered that in C# you have to tell the type of the variable when you declare it.... I think ...

Null in this case, is probably just a new unedited object that haven't been assigned a value to cast to. Not 100% in Lazlos case, but the type "object" is at its core, what every type is at its base. When you say "object" = mynewTypeOfObject it is allowed to now become assigned any type. Because it's still known as just a generic object, which is anything and everything. That's why this works, and why you have so many green ports. Easy to be any type at any time. So you are in fact telling it's type when being declared, but you are declaring it as a generic object that is allowed to be assigned to other object. When you get that information from an object, you usually tell it at runtime to cast. (mynewTypeOfObject)thisObject. That's the only way it knows. If the information set to this object is different then the cast, you get an error.

Fair enough, but here is the issue, when the variable is checked at run time it throws null reference errors for the type at run time.

If the variable value is not assigned, it will still error (regardless of whether the type is remembered.  If it remembers the type but the value is still null, trying to use the value directly will still result in exceptions).  To guard against a case where the type is allowed to be null, consider using the Null Check or Null Coalesce units.  These allow you to react to cases where a value hasn't been assigned yet in the graph.

I was running into the issue using Bolt with Behavior Designer.  I had several variable that are nullable and that is fine but with the types also being null it threw error when syncing with Behavior designer.  I worked around it by having behavior designer sync to Bolt as a first action so that the types were not null.  Can't say I like it though.  What's the benefit, in C#, of having the variables not be strongly typed?  The units all have compatible input types.  Seems that it would be a good idea to prevent a variable that should be a GameObject from having an integer assigned to it.


Cleaning up old issues! Type hinting isn't necessary anymore in Bolt 2's strongly typed variable system, which will land in v.2.0.0a6, so I'm marking this as completed.

Hi! I was trying to implement a nullable float on my Bolt Script but it throws the following error: InvalidOperatorException: Operator '-' cannot be applied to operands of type 'null' and 'null'

Is there a way to set the float value to nullable from the variables on the inspector (or any other way to do that)?

I want to use a basic c#:  float? (variable);