Use struct or not

Question

I made a tiny wrapper for fluent precondition assertions in c#.

Now basically in all public / contract methods i assert the values this way:

Precondition
            .For(()=>Model)
            .NotNull();

Precondition creates a ValidationRule Instance on which I have the given validation methods.

Now this happens very often and I think that using a struct might be an advantage, also because that ValidationRule only has values, there will be no boxing at all, it is sealed by definition and it is immutable. Also they aren't used as parameters or event outside the scope of the calling methods.

But the contra is that it has multiple values and there for not that small footprint.

The ValidationRule looks basically like this:

 public sealed class ValidationRule<T>
    {
        public T Value { get; }

        public string Name { get; }

        public string File { get; }

        public string Source { get; }

        public int Line { get; }

        public ValidationRule(T value, string name, string file, string source, int line)
        {
            Value = value;
            Name = name;
            File = file;
            Source = source;
            Line = line;
        }

        public ValidationRule<T> NotNull()
        {
            if (Value == null)
            {
                throw new ArgumentNullException(Name, "Value must not be null!");
            }
            return this;
        }

        public ValidationRule<T> NotDefault()
        {
            T val = default(T);
            if (Value.Equals(val))
            {
                throw new ArgumentException(Name, "Value must have default value!");
            }
            return this;
        }

So to struct or not ? And most important why?

Keep in mind that, if you're going to implement it as a `struct`, there's more work to do. You _must_ properly implement `GetHashCode` and `Equals` for it to have correct value semantics. — KChaloux, Feb 16 '17 at 13:29
thanks for your hint but i'm aware of this. :-) My question is more related to wether it has good or bad impact on the runtime — Boas Enkler, Feb 16 '17 at 13:31

RubberDuck · Accepted Answer · 2017-02-17T10:47:33.840

✓ CONSIDER defining a struct instead of a class if instances of the type are small and commonly short-lived or are commonly embedded in other objects.

X AVOID defining a struct unless the type has all of the following characteristics: It logically represents a single value, similar to primitive types (int, double, etc.). It has an instance size under 16 bytes. It is immutable. It will not have to be boxed frequently.

In all other cases, you should define your types as classes.

MSDN: Choosing between struct and class

Your class is 20 bytes (assuming you add a where class filter to the T), so it's the right size, but there's not a default instance that would make any sense. You have implemented it immutably (so far as I can tell), so it could be a struct.

So it really boils down to what T can be and whether or not you foresee this getting boxed and unboxed a lot. If T can be a value type or it's going to get boxed a lot, stick with a class. Otherwise.... still stick with a class. Struct's should really represent simple values.

The reason for those rules above is because a struct is stored on the CPU stack, and you do need to be careful that you don't put too much on there needlessly. In all likelihood you won't need to worry about this but it should be considered that you shouldn't make a zillion structs for everything — Dessus, Apr 05 '17 at 22:26

Use struct or not

1 Answers1

Linked