Usually a default constructor is called on a pad if one is not explicitly stated. For most types this seems to be the case. Here is an example where this does not happen:
This also happens with Observer, BehaviorSubject, and I believe I saw it in custom datatypes as well a while ago. It would be useful if a constructor is always automatically called, this issue has led to some difficult-to-diagnose bugs.
EDIT:
Something odd seems to be happening with constructors. If I run the following patch, the renderer window refuses to show up. Once I clear the assignment of the MouseNotification constructor, the renderer window appears, albeit without a rectangle. And then once I re-assign it to Create, the rectangle finally appears.
Hi maro, we are not calling the default constructor. There will only be a value if the type or imported type has a CreateDefault operation. It can be written in c# or in vl. The types you mentioned don’t have a CreateDefault.
Your second problem seems to be a crash on create, then nothing gets constructed.
Wouldn’t it make more sense, for the sake of consistency, that all types in the standard library have a CreateDefault, though? Or is there a specific reason why some do and others don’t?
I still don’t think I understand, I have only seen this happen with MouseNotification and MouseButtonNotification. It’s not a huge issue though, I just noticed it and thought the two might be related.
it’s true that it would make sense for convenience, but it can only be solved for Records in a consistent way, and VL also creates that for you if you make a record. the cool thing with records (and most C# structs) is that you can define one value that get’s used everywhere, since it’s immutable.
for classes this is much more difficult because the system would need to create a new instance every time. and since this also has to work for every input pin in the same way, it can become a performance and memory problem if you create new instances every frame on update. if we would use the same default value everywhere, like we do for records, every change to the default instance would change it in every place where the default value is used, since it’s a mutable reference type.
so for now we almost never create a default value for classes, except NULL. it’s also sometimes better to get an exception instead of a default value because it tells you that you did something wrong instead of working on a default value.
in your particular case, we could indeed think if calling the default parameterless constructor for a class, if it exists. but only for pads, it’s not so easy to generalize this for input pins.
