In the previous posts of this series we've learned that in some scenarios, despite the syntax leading us to believe the contrary, struct constructors may not be executed.
Being aware of this behavior is important and special care should be taken when defining public APIs (specially in libraries due to the potential reach of those) to avoid ending up with APIs that are unintuitive and/or error prone due to developers easily falling into the trap of using uninitialized struct1 members.
That said, this behavior is not new; problems like the ones discussed in post #5, #6 and #7 existed since the first versions of the language; however the introduction, in C# 10, of the ability to define parameterless constructors in structs adds more complexity and makes it more likely that developers will be exposed to such types2.
So, if you are consuming struct types be careful to not end up using uninitialized1 instances. By the other hand, take special care when defining new struct types, specially those with parameterless constructors or a constructor with all of its parameters being optional.
And so we reach the final post in this series. I hope you’ve enjoyed the journey, possibly have learned something new, and now feels better prepared to use and define your own structs.
As always, all feedback is welcome.
Have fun and see you in the next post!
-
Note of clarification: From the perspective of the runtime, structs are guaranteed to be initialized (by zeroing out the whole struct) before being used. Initialization in the context of this series means that all struct fields/properties have been assigned meaningful values leaving the instance in a consistent/valid state.↩↩
-
Prior to C# 10, the only way a developer would be exposed to such types would be by consuming assemblies built with a language supporting that feature, such as IL; personally I am not aware of a single instance of such types.↩
No comments:
Post a Comment