We Keep Coding

Implicit cast operator and the equality operator

Say I have a simple object which supports implicit casting to System.String
public sealed class CompanyCode
{
public CompanyCode(String value)
{
{ Regex validation on value format }
_value = value;
}
readonly String _value;
public override String ToString() => _value;
static public implicit operator String(CompanyCode code) =>
code?.ToString();
}
Now lets say in another part of my program I perform a comparison with a string:
var companyCode = { some company code object }
if (companyCode == "MSFTUKCAMBS")
// do something...
What is the compiler doing with the == operator? Is it implicitly casting companyCode to a string and running the System.String == implementation? Is it using the System.Object == implementation? Or will the compiler just complain at me? (I don't have a compiler to check this right now).
As far as I can see I have a couple of other options.
Implement an ==(String x) operator on CompanyCode.
Implement the IEquatable<String> interface on CompanyCode.
Would any (or both) of these options be preferable?

Say I have a simple object which supports implicit casting to System.String
I would question this design decision to start with. The fact that it's brought up this question of operator overloading suggests that your colleagues will be asking the same sort of questions. I don't even know the answer (in terms of what the compiler will do) off the top of my head.
I definitely wouldn't suggest implementing IEquatable<string>, as then x.Equals(y) won't be symmetric with y.Equals(x). You could implement two overloads of == in your class, both ways round... but then it wouldn't be consistent with Equals.
I would suggest just having a property called Value or Code of type string, then you can use:
if (companyCode.Value == "MSFTUKCAMBS")
and it will be immediately clear what that means.
Basically, I think the situations where implicit conversions are appropriate are very few and far between.
From the Design Guidelines for Class Library Developers
Do not provide a conversion operator if such conversion is not clearly expected by the end users.
Is there such a clear expectation here?

It will implicitly cast to a string and check equality using the string's == operator.
For the case you show - every way you offered is suitable, but every way has a different purpose and meaning.
Implicitly conversion should usually be avoided.
Implementing the == is to allow comparing with a string,
and IEquatable is simply to allow using the class as type IEquatable, for outside code references. The IEquatable may very well just return the == result.
For this case, I would choose the == operator overloading, unless you have any other purpose for using implicit conversion.
Also, if you use implicit conversions, it will be a bit uglier code-wise but smarter robust-wise to overload an EXPLICIT conversion, and not an implicit one, so whenever one wants to convert your class to a string, he will have to cast it using (string)obj, which is also a good reminder for whats really happening in the code.

I personally would suggest do not use operator overloading, in these cases. It's kind of confusing looking on the code, to understand what is going on.
It's a much better, imo, having some function that esplicitly manifests comparison operation, or, like Jon suggests, use a property.
In short make it clear for the reader of your code what you're gonna to compare.

Why can't we do 'if (object)' in C# to test if object is null?

In C, in order to test if a pointer is null we can do:
if (p != NULL)
if (p != 0)
if (p)
Why isn't there any equivalent in C# that would allow us to do the following?
if (object)
instead of
if (object != null)

Because tests of that nature could lead to unexpected bugs in programs, thus they favored requiring boolean expressions to be explicit (as did Java), instead of performing an implicit conversion to bool.
This is also the same reason why you cannot use an int as a boolean expression in C#. Since the only valid boolean expressions are expressions that evaluate directly to bool, this keeps unexpected errors from being introduced in the code, such as the old C gotcha:
if (x = 5)
{
// always true
}
So, in short, it was not included in order to favor readability and explicitness. Yes, it does come at a slight cost in brevity, but the gains in reduction of unexpected bugs more than make up for the cost of hainvg to add != null inside the parenthesis...
(You can, of course, create an implicit conversion of a custom type to bool, as a workaround, but you can't globally apply that to any object type)

Why isn't there any equivalent in C# that would allow us to do the following?
In order to be used a feature must first be:
thought of
designed
specified
approved
implemented
tested
shipped
The feature you mention has been thought of. It has not been designed, specified or approved by the design committee, it has not been implemented by the development team, it has not been tested, and it has never shipped in any product. Therefore you cannot use the feature.
If that doesn't answer your question then ask a better question. Asking why a language doesn't have a feature is like asking why a box is empty. Every empty box is empty for the same reason: because there's nothing in it. Every unavailable feature is unavailable because it was never shipped to customers, and there's not much more to say about it.

Technically speaking it doesn't work because there is no implicit conversion possible from your custom object class to bool (boolean). As long as you provide an implicit conversion operator, that might check your object for null, you can go ahead with your syntax:
public static implicit operator bool(MyType p)
{
return (p != null) && (p != 0);
}
Integrating the suggestion by Dan Bryant:
An alternative way is to implement implicit "true" and "false" operators for your data type. You might need this if your type allow tri-state evaluation to bool: true, false and null. This is quite a common case in databases where the null value designates missing data. Here is an example from the MSDN webpage:
public static bool operator true(DBBool x)
{
return x.value > 0;
}
public static bool operator false(DBBool x)
{
return x.value < 0;
}

Because that's how the language designers designed the language. Partially it's to prevent dumb mistakes like:
if (p = 42)

Because an Object is not a Pointer, it is an Object.

Because it is not in C# specification and the compiler does not understand such expression.
And if you are after the reason why it is not used in this way in C# - from my point of view it is totally illogical to check something for null in a manner if(object).
If object what?

Your example looks readable only because your object is named 'object'. In reality objects have names that derive from their use/function. If your object was called 'validatedWidget' then your code would look like
if (validatatedWidget)
{
// do something
}
Which would incorrectly imply something where as:
if (validatedWidget != null)
{
// do something
}
Is far more explicit, and is hardly a lot of work.

Syntax of if statement is ::
if(condition)
and the result of condition should be boolean i.e. true or false.
So we do write any condition like
x = 10;
if(x == 10)
but if(object) does not make a specific condition to result out as a boolean result.
if we write
boolean object = true;
if(object)
then it will be perfectly fine.
but to see if any object is null or not we can't write if(object) we need to write it as if(object == null) or if(object != null), because such conditions will result in boolean result.

Why do Java and C# not have implicit conversions to boolean?

Since I started Java it's been very aggravating for me that it doesn't support implicit conversions from numeric types to booleans, so you can't do things like:
if (flags & 0x80) { ... }
instead you have to go through this lunacy:
if ((flags & 0x80) != 0) { ... }
It's the same with null and objects. Every other C-like language I know including JavaScript allows it, so I thought Java was just moronic, but I've just discovered that C# is the same (at least for numbers, don't know about null/objects):
http://msdn.microsoft.com/en-us/library/c8f5xwh7(VS.71).aspx
Microsoft changed it on purpose from C++, so why? Clearly I'm missing something. Why change (what I thought was) the most natural thing in the world to make it longer to type? What on Earth is wrong with it?

For clarity. It makes the following mistake simply illegal:
int x = ...;
if (x = 0) // in C: assign 0 to x and always evaluate to false
.... // never executed
Note: most modern C / C++ compilers will give a Warning (but not an Error) on this straightforward pattern, but there are many variations possible. It can creep up on you.

Both Java and C# abandoned implicit conversions to booleans to reduce the chance of programmer error.
For example, many programmers would accidentally write:
if( x = 5 ) { ... }
instead of:
if( x == 5 ) { ... }
Which of course results in completely different behavior, since the first statement performs an assignment (which will always result in true), while the second performs a comparison. In the past, developers would sometimes write such assignments in reverse to avoid the pitfall, since:
if( 5 = x ) { ... } // doesn't compile.
Now, in C#, you can still create implicit conversion operators to bool for your own types - although it is rarely advisable, since most developers don't expect it:
public class MyValue
{
public int Value { get; set; }
public static implicit operator bool( MyValue mb )
{
return mb.Value != 0;
}
}
MyValue x = new MyValue() { Value = 10; }
if( x ) { ... } // perfectly legal, compiler applies implicit conversion

Maybe they felt that being more explicit was more in line with a strongly typed language.

You've got it backward.
It's actually C that does not support boolean, so if ( and any other conditional statement ) actually expects an int value, not boolean. Then int value of 0 is treated as false and any other value is treated as true.
Some people actually find it a little ambiguous, because this type of behavior can lead to many errors, as others have pointed out. Because of this, Java designers have opted out to support only boolean types in the condition statements. And when Microsoft decided to implement MS-Java ( AKA C# ), they've borrowed this design principal.
If you don't like it, you can program in a variety of languages that do not have this restriction.

Implicit conversion of any int value (such as (flags & 0x80)) to a boolean implies a language defined mapping from an int value to a boolean. C did this, and caused a huge amount of confusion and a lot of programmer error. There is no good reason why a zero int value ALWAYS means true (or false) and a lot of good reasons why you might want to leave the decision to the programmer. For these reasons implicit conversion to boolean has been abandoned by most modern languages.
If typing seven extra characters every time you do a bit test constitutes 'lunacy' you may be in the wrong profession. If you are doing bit tests in an int extremely frequently you might want to think about whether you are prematurely optimizing to save memory.

Even the most experienced programmers have problems with an implicit conversion to boolean. I for one appreciate this little feature.

Some programming languages do no automatic coercion at all. An integer, for example, can only be compared to another integer; assignment to a non-integer variable results in an error. Such is the hallmark of a strongly-typed language.
That Java does any coercion is a convenience for you and breaks the strong-typing model.
Mapping the entire range of integers -- or the even larger range of floats -- onto the two boolean values is fraught with disagreement over arbitrary assignment of "truthness" and "falseness".
What values map onto false and true? If you're C, only zero maps to false and all other values are true. If you're the bash shell, it's reversed.
How should negative values be mapped?
When you try to automatically convert a double to an integer, Java flags this as a "loss of precision" error. By analogy, converting a number to a boolean should also result in a loss of precision. Instead, Java chose to not syntactically support it.

In C#, What is a monad?

There is a lot of talk about monads these days. I have read a few articles / blog posts, but I can't go far enough with their examples to fully grasp the concept. The reason is that monads are a functional language concept, and thus the examples are in languages I haven't worked with (since I haven't used a functional language in depth). I can't grasp the syntax deeply enough to follow the articles fully ... but I can tell there's something worth understanding there.
However, I know C# pretty well, including lambda expressions and other functional features. I know C# only has a subset of functional features, and so maybe monads can't be expressed in C#.
However, surely it is possible to convey the concept? At least I hope so. Maybe you can present a C# example as a foundation, and then describe what a C# developer would wish he could do from there but can't because the language lacks functional programming features. This would be fantastic, because it would convey the intent and benefits of monads. So here's my question: What is the best explanation you can give of monads to a C# 3 developer?
Thanks!
(EDIT: By the way, I know there are at least 3 "what is a monad" questions already on SO. However, I face the same problem with them ... so this question is needed imo, because of the C#-developer focus. Thanks.)

Most of what you do in programming all day is combining some functions together to build bigger functions from them. Usually you have not only functions in your toolbox but also other things like operators, variable assignments and the like, but generally your program combines together lots of "computations" to bigger computations that will be combined together further.
A monad is some way to do this "combining of computations".
Usually your most basic "operator" to combine two computations together is ;:
a; b
When you say this you mean "first do a, then do b". The result a; b is basically again a computation that can be combined together with more stuff.
This is a simple monad, it is a way of combing small computations to bigger ones. The ; says "do the thing on the left, then do the thing on the right".
Another thing that can be seen as a monad in object oriented languages is the .. Often you find things like this:
a.b().c().d()
The . basically means "evaluate the computation on the left, and then call the method on the right on the result of that". It is another way to combine functions/computations together, a little more complicated than ;. And the concept of chaining things together with . is a monad, since it's a way of combining two computations together to a new computation.
Another fairly common monad, that has no special syntax, is this pattern:
rv = socket.bind(address, port);
if (rv == -1)
return -1;
rv = socket.connect(...);
if (rv == -1)
return -1;
rv = socket.send(...);
if (rv == -1)
return -1;
A return value of -1 indicates failure, but there is no real way to abstract out this error checking, even if you have lots of API-calls that you need to combine in this fashion. This is basically just another monad that combines the function calls by the rule "if the function on the left returned -1, do return -1 ourselves, otherwise call the function on the right". If we had an operator >>= that did this thing we could simply write:
socket.bind(...) >>= socket.connect(...) >>= socket.send(...)
It would make things more readable and help to abstract out our special way of combining functions, so that we don't need to repeat ourselves over and over again.
And there are many more ways to combine functions/computations that are useful as a general pattern and can be abstracted in a monad, enabling the user of the monad to write much more concise and clear code, since all the book-keeping and management of the used functions is done in the monad.
For example the above >>= could be extended to "do the error checking and then call the right side on the socket that we got as input", so that we don't need to explicitly specify socket lots of times:
new socket() >>= bind(...) >>= connect(...) >>= send(...);
The formal definition is a bit more complicated since you have to worry about how to get the result of one function as an input to the next one, if that function needs that input and since you want to make sure that the functions you combine fit into the way you try to combine them in your monad. But the basic concept is just that you formalize different ways to combine functions together.

It has been a year since I posted this question. After posting it, I delved into Haskell for a couple of months. I enjoyed it tremendously, but I placed it aside just as I was ready to delve into Monads. I went back to work and focused on the technologies my project required.
And last night, I came and re-read these responses. Most importantly, I re-read the specific C# example in the text comments of the Brian Beckman video someone mentions above. It was so completely clear and illuminating that I’ve decided to post it directly here.
Because of this comment, not only do I feel like I understand exactly what Monads are … I realize I’ve actually written some things in C# that are Monads … or at least very close, and striving to solve the same problems.
So, here’s the comment – this is all a direct quote from the comment here by sylvan:
This is pretty cool. It's a bit abstract though. I can imagine people
who don't know what monads are already get confused due to the lack of
real examples.
So let me try to comply, and just to be really clear I'll do an
example in C#, even though it will look ugly. I'll add the equivalent
Haskell at the end and show you the cool Haskell syntactic sugar which
is where, IMO, monads really start getting useful.
Okay, so one of the easiest Monads is called the "Maybe monad" in
Haskell. In C# the Maybe type is called Nullable<T>. It's basically
a tiny class that just encapsulates the concept of a value that is
either valid and has a value, or is "null" and has no value.
A useful thing to stick inside a monad for combining values of this
type is the notion of failure. I.e. we want to be able to look at
multiple nullable values and return null as soon as any one of them
is null. This could be useful if you, for example, look up lots of
keys in a dictionary or something, and at the end you want to process
all of the results and combine them somehow, but if any of the keys
are not in the dictionary, you want to return null for the whole
thing. It would be tedious to manually have to check each lookup for
null and return, so we can hide this checking inside the bind
operator (which is sort of the point of monads, we hide book-keeping
in the bind operator which makes the code easier to use since we can
forget about the details).
Here's the program that motivates the whole thing (I'll define the
Bind later, this is just to show you why it's nice).
class Program
{
static Nullable<int> f(){ return 4; }
static Nullable<int> g(){ return 7; }
static Nullable<int> h(){ return 9; }
static void Main(string[] args)
{
Nullable<int> z =
f().Bind( fval =>
g().Bind( gval =>
h().Bind( hval =>
new Nullable<int>( fval + gval + hval ))));
Console.WriteLine(
"z = {0}", z.HasValue ? z.Value.ToString() : "null" );
Console.WriteLine("Press any key to continue...");
Console.ReadKey();
}
}
Now, ignore for a moment that there already is support for doing this
for Nullable in C# (you can add nullable ints together and you get
null if either is null). Let's pretend that there is no such feature,
and it's just a user-defined class with no special magic. The point is
that we can use the Bind function to bind a variable to the contents
of our Nullable value and then pretend that there's nothing strange
going on, and use them like normal ints and just add them together. We
wrap the result in a nullable at the end, and that nullable will
either be null (if any of f, g or h returns null) or it will be
the result of summing f, g, and h together. (this is analogous
of how we can bind a row in a database to a variable in LINQ, and do
stuff with it, safe in the knowledge that the Bind operator will
make sure that the variable will only ever be passed valid row
values).
You can play with this and change any of f, g, and h to return
null and you will see that the whole thing will return null.
So clearly the bind operator has to do this checking for us, and bail
out returning null if it encounters a null value, and otherwise pass
along the value inside the Nullable structure into the lambda.
Here's the Bind operator:
public static Nullable<B> Bind<A,B>( this Nullable<A> a, Func<A,Nullable<B>> f )
where B : struct
where A : struct
{
return a.HasValue ? f(a.Value) : null;
}
The types here are just like in the video. It takes an M a
(Nullable<A> in C# syntax for this case), and a function from a to
M b (Func<A, Nullable<B>> in C# syntax), and it returns an M b
(Nullable<B>).
The code simply checks if the nullable contains a value and if so
extracts it and passes it onto the function, else it just returns
null. This means that the Bind operator will handle all the
null-checking logic for us. If and only if the value that we call
Bind on is non-null then that value will be "passed along" to the
lambda function, else we bail out early and the whole expression is
null. This allows the code that we write using the monad to be
entirely free of this null-checking behaviour, we just use Bind and
get a variable bound to the value inside the monadic value (fval,
gval and hval in the example code) and we can use them safe in the
knowledge that Bind will take care of checking them for null before
passing them along.
There are other examples of things you can do with a monad. For
example you can make the Bind operator take care of an input stream
of characters, and use it to write parser combinators. Each parser
combinator can then be completely oblivious to things like
back-tracking, parser failures etc., and just combine smaller parsers
together as if things would never go wrong, safe in the knowledge that
a clever implementation of Bind sorts out all the logic behind the
difficult bits. Then later on maybe someone adds logging to the monad,
but the code using the monad doesn't change, because all the magic
happens in the definition of the Bind operator, the rest of the code
is unchanged.
Finally, here's the implementation of the same code in Haskell (--
begins a comment line).
-- Here's the data type, it's either nothing, or "Just" a value
-- this is in the standard library
data Maybe a = Nothing | Just a
-- The bind operator for Nothing
Nothing >>= f = Nothing
-- The bind operator for Just x
Just x >>= f = f x
-- the "unit", called "return"
return = Just
-- The sample code using the lambda syntax
-- that Brian showed
z = f >>= ( \fval ->
g >>= ( \gval ->
h >>= ( \hval -> return (fval+gval+hval ) ) ) )
-- The following is exactly the same as the three lines above
z2 = do
fval <- f
gval <- g
hval <- h
return (fval+gval+hval)
As you can see the nice do notation at the end makes it look like
straight imperative code. And indeed this is by design. Monads can be
used to encapsulate all the useful stuff in imperative programming
(mutable state, IO etc.) and used using this nice imperative-like
syntax, but behind the curtains, it's all just monads and a clever
implementation of the bind operator! The cool thing is that you can
implement your own monads by implementing >>= and return. And if
you do so those monads will also be able to use the do notation,
which means you can basically write your own little languages by just
defining two functions!

A monad is essentially deferred processing. If you are trying to write code that has side effects (e.g. I/O) in a language that does not permit them, and only allows pure computation, one dodge is to say, "Ok, I know you won't do side effects for me, but can you please compute what would happen if you did?"
It's sort of cheating.
Now, that explanation will help you understand the big picture intent of monads, but the devil is in the details. How exactly do you compute the consequences? Sometimes, it isn't pretty.
The best way to give an overview of the how for someone used to imperative programming is to say that it puts you in a DSL wherein operations that look syntactically like what you are used to outside the monad are used instead to build a function that would do what you want if you could (for example) write to an output file. Almost (but not really) as if you were building code in a string to later be eval'd.

You can think of a monad as a C# interface that classes have to implement. This is a pragmatic answer that ignores all the category theoretical math behind why you'd want to choose to have these declarations in your interface and ignores all the reasons why you'd want to have monads in a language that tries to avoid side effects, but I found it to be a good start as someone who understands (C#) interfaces.

See my answer to "What is a monad?"
It begins with a motivating example, works through the example, derives an example of a monad, and formally defines "monad".
It assumes no knowledge of functional programming and it uses pseudocode with function(argument) := expression syntax with the simplest possible expressions.
This C# program is an implementation of the pseudocode monad. (For reference: M is the type constructor, feed is the "bind" operation, and wrap is the "return" operation.)
using System.IO;
using System;
class Program
{
public class M<A>
{
public A val;
public string messages;
}
public static M<B> feed<A, B>(Func<A, M<B>> f, M<A> x)
{
M<B> m = f(x.val);
m.messages = x.messages + m.messages;
return m;
}
public static M<A> wrap<A>(A x)
{
M<A> m = new M<A>();
m.val = x;
m.messages = "";
return m;
}
public class T {};
public class U {};
public class V {};
public static M<U> g(V x)
{
M<U> m = new M<U>();
m.messages = "called g.\n";
return m;
}
public static M<T> f(U x)
{
M<T> m = new M<T>();
m.messages = "called f.\n";
return m;
}
static void Main()
{
V x = new V();
M<T> m = feed<U, T>(f, feed(g, wrap<V>(x)));
Console.Write(m.messages);
}
}

Would a conditional de-reference operator be a good thing in C#?

In functional languages there is often a Maybe monad which allows you to chain multiple calls on an object and have the entire expression return None/null if any part of the chain evaluates to nothing, rather than the typical NullReferenceException you'd get in C# by chaining calls where one object could be null.
This can be trivially implemented by writing a Maybe<T> with some extension methods to allow similar behaviour in C# using query comprehensions, which can be useful when processing XML with optional elements/attributes e.g.
var val = from foo in doc.Elements("foo").FirstOrDefault().ToMaybe()
from bar in foo.Attribute("bar").ToMaybe()
select bar.Value;
But this syntax is a bit clunky and unintuitive as people are used to dealing with sequences in Linq rather than single elements, and it leaves you with a Maybe<T> rather than a T at the end. Would a conditional de-reference operator (e.g. ..) be sufficiently useful to make it into the language? e.g.
var val = doc.Elements("foo").FirstOrDefault()..Attribute("bar")..Value;
The conditional de-reference would expand to something like:
object val;
var foo = doc.Elements("foo").FirstOrDefault();
if (foo != null)
{
var bar = foo.Attribute("bar");
if (bar != null)
{
val = bar.Value;
}
else
{
val = null;
}
}
I can see that this could potentially lead to terrible abuse like using .. everywhere to avoid a NullReferenceException, but on the other hand when used properly it could be very handy in quite a few situations. Thoughts?

Chaining multiple calls on an object makes me fear violations of the Law of Demeter. Thus, I am skeptical that this feature is a good idea, at least in terms of solving the specific problem you are using as an example.

It's an interesting idea that could be achieved with an extension method. Something like this, for example (note, just for example - I'm sure it can be refined):
public static IEnumerable<T> Maybe<T>(this IEnumerable<T> lhs, Func<IEnumerable<T>, T> rhs)
{
if (lhs != null)
{
return rhs(lhs);
}
return lhs;
}

I suspect a combination of NUllable and extension methods would allow a significant portion of this to b achieved.
This would limit T to value types of course.
(TBH I would rather see tuple support in the langauge and eliminate out parameters, as F# does.)
You code can be simplified, set val to null and you eliminate else branches.

I can see the potential usefulness, but other than a slight performance impact if the elements are often null, why not just surround the code block with a try..catch block for a NullReferenceException instead?