
0
Not a Bug
AllowsNull and interface default detection
Interesting experience: it appears that the presence of an interface is fooling the Bolt reflection relevant interface:
Given this interface:
public interface Industrial { void AddToProducedGoods(ResourceDefinition resource, int amount); void Tick(ResourceStorage targetStorage); }
I had an implementation with this routine:
public void Tick([AllowsNull]ResourceStorage targetStorage = null) { // ... }
both a default parameter and [AllowsNull] have been added overtop of the interface specification. This is perfectly valid C#, as it DOES take the parameter, and I only want it defaulted in this class, not all implementations.
However, Bolt complains:
If I attempt to let the game run, I get:
Odds are, I'm doing something foolish again, and I'm not sure that it is the interface fooling it, but I thought it useful to post in the event that anyone finds more detailed information or duplication steps.
Bolt Version:
Unity Version:
Platform(s):
Scripting Backend:
.NET Version (API Compatibility Level):
Customer support service by UserEcho
Well there are two different things here.
For the error, no-connection does not mean null in Bolt, unless you see a default value inspector next to the field name.
In this case, you'd have to pass Null as a unit to avoid the error.
Now, for the null detection warning, here's the actual underlying code:
IsReferenceType is just the opposite of IsValueType in .NET.
I don't see the definition of ResourceStorage. Is it a class?
yeah, there's a lot of reference chaining, so I only posted a snippet, it is a class, but I think this was just me misunderstanding how Bolt will handle default parameters. In this case, I want the default parameter to be used. If the default wasn't null, how do I get Bolt to allow the default through?
Also, I don't see any issues with Null in what I posted. I misunderstood what the missing warning meant. I thought that it meant it was seeing the default, but complaining because it didn't allow null. In hindsight, it seems that it handles defaults differently than I expect, and it was just complaining that nothing was wired to the port is all (and there is no problem with null)
Indeed! The "is missing" warning means no connection, whereas "cannot be null" means there is a value that's found, but it is and shouldn't be null. There is no way to allow a null as a default input at the moment (except for GameObjects / Unity Objects that can be left to "None").