title: Is it a bad practice to base logic on assumption that a type is a struct?
body: <p>In my current project, I need to throw a lot of data around with a good understanding of what is a copy and what is a reference, in particular — implement a lot of deep cloning. Thankfully, a lot of my data is contained in simple structs, so I can just assign them or pass them as parameters and be sure that they aren't referencing each other.</p>
  
  <p>However, I realized that the code that is doing that is based on assumption that these types are struct, and that if anyone is going to change their type to a class some time down the road, they may not notice errors right away, and when they do, it will be a hell to debug.</p>
  
  <p>In general, I consider code which correctness is based on assumption that is not explicitly stated in the same file to be a smell, and especially when this assumption can be changed without immediately breaking the build. So, this situation really gives a bad smell for me.</p>
  
  <p>Is what I'm doing really a bad practice? Have you experienced any problems that I described in real codebases, or am I imagining things? And if you have, what would be a good way to make things more explicit?</p>
  
  <hr>
  
  <p>Here's an example of what I'm talking about (this is my actual code, with all names changed and other functionality stripped):</p>
  
  <pre><code>public class Example
  {
      public readonly DataOfType;
      public readonly DataOfOtherType;
  
      public Example(Type _DataOfType, OtherType _DataOfOtherType)
      {
          DataOfType = _DataOfType;
          DataOfOtherType = _DataOfOtherType;
      }
  
      public Example DeepClone()
      {
          return new Example(DataOfType, DataOfOtherType);
      }
  }
  </code></pre>
  
  <p>The <code>DeepClone</code> method is correct because <code>Type</code> is an enum and <code>OtherType</code> is a struct, but you would never know it from this code.</p>