Issues with Some.cs

[tejacques]

I think two changes should be made to Some.cs

First change: The overrides which call CheckInitialized should call their methods on the return value of CheckInitialized, rather than the value they pass in:

public override string ToString() =>
    CheckInitialised(Value.ToString());

public override int GetHashCode() =>
    CheckInitialised(Value.GetHashCode());

public override bool Equals(object obj) =>
    CheckInitialised(Value.Equals(obj));

Should be

public override string ToString() =>
    CheckInitialised(Value).ToString();

public override int GetHashCode() =>
    CheckInitialised(Value).GetHashCode();

public override bool Equals(object obj) =>
    CheckInitialised(Value).Equals(obj);

Reason:

If Value is not initialized it could have another exception thrown (such as NPE) because it's calling a method on Value before checking whether Value is initialized.

Second change: It's not enough to only check (and throw) in the default constructor because the CLR will not call the default constructor on arrays of structs.

Example:

var someThings = new Some<object>[100];
Console.WriteLine(someThings[0].Value == null); // Prints true, no exception raised

Reason:

For performance reasons, the CLR will not call the default constructor on struct arrays. It will only zero out the memory associated with them. You'll have to raise an error in the getter property to catch this case.

[louthy]

First change: The overrides which call CheckInitialized ...

Yep, some silly mistakes there. I've taken a different approach to fixing it:

        public T Value => 
            CheckInitialised(value);

        public static implicit operator T(Some<T> value) => 
            value.Value;

        public override string ToString() =>
            Value.ToString();

        public override int GetHashCode() =>
            Value.GetHashCode();

        public override bool Equals(object obj) =>
            Value.Equals(obj);

It puts slightly more burden on the Value access, but I think overall it's cleaner.

For performance reasons, the CLR will not call the default constructor on struct arrays.

It's not the CLR, it's the C# compiler. It could easily call the same series of op-codes that it does for classes. It is however (like you say) an optimisation. I believe the C# team are discussing default constructors for the final C# 6. So we'll see how that goes. Until then Some<T> will always be a weak solution to this problem.

I do discuss this on the project home page, and explain its limitations. I think only using Some<T> for method arguments, and never instantiating them manually is probably the best use of a weak solution.

Thanks for the heads up on the bugs!

[tejacques]

No problem -- I like the way you handled everything, I think that makes it work out nicely. Closing this issue now.