Making the code read like the spec

re: Making the code read like the spec

runefs — Wed, 10 Mar 2010 09:51:24 GMT

I'm wondering why you're not simply applying a graph library where every node in a directed graph would be a type and every edge from that node would represent a direct dependency to the connected node. Then search for cycles in the graph. I'm sure there are reasons I would just find them interesting to read about

That would answer the question "are there any types with cycles in their base classes?" The question I actually needed to answer was "does this particular type declaration have cycles in its base class?" I can answer that question by simply constructing the set of dependencies; no need to build a graph of all types.

I recently implemented Andrew Kennedy's algorithm for identifying infinitary types given a set of nominal base type relations; in that algorithm I use something like the approach you suggest. -- Eric

re: Making the code read like the spec

Alois Kraus — Wed, 17 Feb 2010 20:43:22 GMT

I would like the ~> operator for null checks. What syntax it has ~> or .? is a non issue. Is this "automatic" null check seriously considered for version next of C#? I do not know who did initially have the idea of the .? operator. But I have written about this quite some time ago at Connect and at my blog: http://geekswithblogs.net/akraus1/archive/2009/11/22/136473.aspx

Yours,

Alois Kraus

re: Making the code read like the spec

Pavel Minaev [MSFT] — Mon, 15 Feb 2010 02:00:00 GMT

> Bit Flag Check (yea, only saves a few keystrokes)

> bool isWuzzleAndWaddle = myEnumVal ~> MyEnum.Wuzzle | MyEnum.Waddle;

In .NET 4, there's a library-provided shorthand:

bool isWuzzleAndWaddle = Enum.HasFlag(myEnumVal, MyEnum.Wuzzle | MyEnum.Waddle)

see http://msdn.microsoft.com/en-us/library/system.enum.hasflag(VS.100).aspx

re: Making the code read like the spec

Dave Sexton — Sun, 14 Feb 2010 02:48:10 GMT

Recursive Lambda (compiler automatically creates IL as a non-overflowing Stack<T>, optimized with tail-recursion, etc.)

var factorial = a ~> (a > 1) ? a * self(a - 1) : a;

(Yea, I just assumed a "self" keyword as well :)

re: Making the code read like the spec

Dave Sexton — Sat, 13 Feb 2010 21:30:48 GMT

Reflection (unlike dynamic, has static checking; enables IntelliSense in VS):

var x = foo~>privateX;

var result = foo~>PrivateBar(x, y, z);

Code as Data (ExpressionTree)

ExpressionTree parse ~> System.Int32.TryParse;

Bit Flag Check (yea, only saves a few keystrokes):

bool isWuzzleAndWaddle = myEnumVal ~> MyEnum.Wuzzle | MyEnum.Waddle;

re: Making the code read like the spec

Erik Källén — Sat, 13 Feb 2010 12:30:09 GMT

@Pavel: I don't think the change is trivial. However, C# 4 focused on those people that want dynamic abilites, now I think it is us "staticist"s turn. Regarding [NotNull], not good enough since I want the compiler to complain. Throwing a NullReferenceException would only be a fallback mechanism where another solution is not practical/possible.

In 99.9 percent of cases, it would be used in the style of

var arg = GetSomeArg();

MyClass! object = GetMyObject(arg);

in which case I want the compiler to say:

argument 1: Cannot convert from SomeType to SomeType! an explicit cast exists.

return value: Cannot convert MyClass to MyClass!, an explicit cast exists.

All other uses are just things that need to be worked around by the compiler writer, with a NullPointerException as a last resort. I'm certain that if they spend their time on doing this, they'll find a good way.

re: Making the code read like the spec

Pavel Minaev [MSFT] — Sat, 13 Feb 2010 11:00:55 GMT

@Erik: but isn't the whole point of a non-null reference type to not have null as a possible value in the first place (thus eliminating NullReferenceException, and all other associated runtime exceptions)? I dare say that a type that is kind-of not null but not really - when you can trivially work around it, and get the old behavior - isn't worth it.

If you just want to throw ArgumentException for null function arguments, then something like [NotNull] attribute specifically for them (and not a whole new type) is probably a better idea. And you can have that alread with PostSharp. Or, in 4.0, use DbC / System.Design.Contracts to validate arguments, including null checks (or,

again, use PostSharp to auto-generate contracts from [NotNull]).

As for the tricky cases above - they can all be handled in one way or another; it just shows that the change isn't as trivial as it seems. For example, in the absence of a well-defined default value for reference types, you'd somehow need to make it so that static fields are not accessible before their initializers run - which would require changing the existing order-of-declaration rule, and introduce recursive dependency checks. For structs, you'd need a default constructor. For arrays, a way to specify the new value for all created elements - either just one value, or a lambda that generates a value given an index. Etc.

re: Making the code read like the spec

Erik Källén — Fri, 12 Feb 2010 14:46:25 GMT

@Pavel: For all that I care, each of those examples could throw some exception. It could even be a NullReferenceException, in which case the codegen wouldn't even have to change, I guess.

re: Making the code read like the spec

Pavel Minaev [MSFT] — Fri, 12 Feb 2010 06:16:24 GMT

@Erik:

It's kind of a trick question, but if you had non-nullable reference types (say, T!), what values would you expect this code to produce?

object![] a = new object![1];

a[0]; // ?

struct Foo { object! x; }

Foo f = new Foo();

f.x; // ?

and a few more tricky cases:

class Base {

abstract void Foo();

Base() { Foo(); }

}

class Derived : Base {

object! o = new object();

override void Foo() {

o; // ? (assume call during instantiation)

}

class Static {

static object! x = y; // ?

static object! y = new object();

}

re: Making the code read like the spec

Erik Källén — Thu, 11 Feb 2010 18:33:08 GMT

What was I thinking? Of course I mean "non-nullable reference types". DOH.