Eric Gunnerson's Compendium

1. I like the mixin style idea, especially if it let's me drop down to IL, and especially if you could nest it. IOW, something like this...

void SomeFuncInCSharp()
{
_IL
{
ldarg.1 // etc. e.g setup try-catch
_C#
{ // back to C#

}

}
}

This sort of construct would make it possible to provide access to some features supported by the runtime but not exposed by C#, such as fault blocks or user-filtered exceptions.

2. Provide a type that provides auto-destruct semantics when it goes out of lexical scope. I know the IDispose and using syntax provides similar functionality, but it is really ugly and forces me to write code like this...

using ( new MyAutoDestructWrapper(o1,o2,o3,o4) )
{
}

where MyAutoDestructWrapper is a class that takes a variable arg list and just calls Dispose on each object when the implicit finally is invoked. It requires extra memory allocations to occur as it must allocate one object plus an array list to track the items. It also forces all objects to go out of scope simultaneously which is not always what is desired. Why make each of us invent this ourselves? It ought to be part of the plumbing.

oops s/implementedBy/providedBy

oh and tack = tacky.

would like to see local method or nested method like it's possible in Delphi

public int DoSomething() {
local int DoSomething1 {
return 1;
}

local int DoSomething2 {
return 2;
}

local int DoSomething3 {
return 3;
}

return DoSomething1() + DoSomething2() + DoSomething3();
}

It'd be nice if you could just go all the way and make functions first-class values. The method-group conversion stuff in Whidbey goes most of the way, but it just seems strange that you've got so close, but haven't quite gone all the way.

On a similarly functional note, i'd also like to see:

Type inference.
AReallyLongClassName foo = new AReallyLongClassName(); //argh.
def foo = new AReallyLongClassName(); //much nicer.
(although you'd probably want public members to be manifestly typed).

Algebraic datatypes and pattern matching would be /very/ useful, for certain things.

i'll second the request for nested functions, too, especially if they could be returned as closures (i'm guessing this wouldn't be too hard, and could largely just piggyback on the work done for anonymous methods).

Oh, and one last, relatively trivial thing: it'd be nice to have a nice syntactic shortcut for defining a List<T>, similar to {1,2,3,4} for arrays.
Just something like:
def foo = [1, 2, 3, 4];

ugh, i can't stand python :P (limp lambda, implicit variable declaration, the brokenness of lexical scoping [partly related to the implicit declarations], etc, and i happen to prefer strict typing where possible) [no offence intended to those who do like python, of course, it's just not my cup 'o tea].

I won't exactly be disappointed if some of the stuff i'd like never makes it into C# (i can always keep using Nemerle [http://nemerle.org], which has just about everything i want, but i'd prefer it if some of those features could make it into a language i have a slightly less remote chance of being paid to work with...), but i figure if there's a chance to get the guys in charge to think about it, it's worth a try ;).

C#'s already (v2, anyway) a pretty passable functional language, i'd just like to see it go a bit further in that direction...

(speaking of which, local methods in particular aren't strictly necessary -- anonymous methods are, afaict, fully-fledged lambdas, and a local method definition is just syntactic sugar for a lambda anyway...)

Ya, I don't like python much either. For the reasons you named plus a general dislike of the syntax and philosophy, however there are a few things I like(lists and list comprehensions specifically).

Nemerle has some interesting features and a few I don't like. I don't like the whole-hog functional approach, especially dynamic typing. I've also seen a thing or two I liked in Boo(don't have a link on hand, sadly), but it is much too pythony for my day to day usage.

Oh, one other thing. I've commented on it a few times and I've seen at least one suggestion on the feedback center about it. I abhor the existing casting operator. It seems to me that it was probably a bad choice. I know it looks like java and C casts, but I don't think its a terribly good design. A keyword like
cast<string>(<expression) is more inline with the rest of the language(especially now that generics exist) and considerably clearer, IMHO.

It might also be of value to consider a "safe" cast(maybe safecast<string>(<expression>)), something that explicitly shows that a cast is occuring but is only valid if the compiler can verify the cast is legal. Its use would be minimal, basically only allowing explicit conversions and base class\interface casts to occur, but I think it could help self-documentation and casting enforcement considerably.

EnC
Enough said.

Inline creation of value types:

struct Money {
decimal amount;
char symbol;
}

static void Main() {
Money wallet={amount:=1.5M, symbol:='£'};

}

arha, Anonymous methods are not quite closures, although they appear similar.

For example, try running this piece of code, and tell me if gives you the results you would expect.

class Program
{
static void Main(string[] args)
{
Test t = new Test();
t.Do();
}
}
delegate void Thing();
class Test
{
List<Thing> things = new List<Thing>();
int _index = 0;
public void Do()
{
for (_index = 0; _index < 10; ++_index)
{
things.Add(delegate { Console.WriteLine(this._index); });
}
things.ForEach(delegate(Thing t) { t(); });
}
}

Kevin: i don't actually have access to a compiler that can compile that, currently (haven't got round to rebooting into windows since the whidbey betas were released, and mono doesn't do anonymous methods yet), but assuming it does what i think you're referring to (print '10' ten times), then that's exactly what i'd expect -- the anonymous method is capturing a reference to the object it's defined in (explicitly, in your code, since you used this._index, rather than relying on the implicit this for member access (or is that an anonymous method limitation? i assume not, but it's worth asking...)), and then when it's called later, it uses the value of the member it gets through that reference, which is obviously the last value it was set to in the for loop.

I assume that if you changed _index to be a local variable, then it would properly close over the value it held at the time the anonymous method was created (the interim C# v2 standard that was recently released certainly gives that impression, since it uses the standard 'counter' example, that gets used in just about every explanation of closures ever written).

In fact, i just tried it out in Nemerle, and got exactly that result (ten '10's). So, as long as C#'s anonymous methods are as good as Nemerle's anonymous functions, i'll be happy :)

The equivalent Nemerle, btw, is:

using Nemerle.Collections;
module M {
Main(): void {
def t = Test();
t.Do();
}
}
class Test {
public this(){things = []}
mutable things : list<(void -> void)>;
mutable i : int;
public Do(): void {
for (i = 0; i < 10; ++i) {
things = things + [fun() { Console.WriteLine(this.i)}];
}
List.Iter(things, fun(t: void -> void) { t() })
}
}

Ooh yeah. Ability to add methods to the class library.

Make it so partial classes can be added after a class has been compiled (Unlike now, where all partial parts must be compiled together)

ala:

partial class System.Object
{
public virtual XmlDocument asXml()
{
return new XmlDocument(ToString());
}
}



and then, wala,

int i = 0;
XmlDocument doc = i.asXml();

Totally useless example, but that would be kind of nice. Sure, people could blow shit up, but isn't that what programming is all about?


oh and virtual by default. Just because its a slight performance boost (to make C# look like its faster than java.....) VIRTUAL BY DEFAULT.

Two related ideas:
Partial generics. One thing I'd like to be able to do is to compose code of lumps of generics. I've wanted to do this recently.
In particular I wanted it for use in a database browsing type scenario so I could have an interface called IBrowsable which I could implement just by sticking in a generic (passing in an instance of my OR mapping object).
There still isn't a replacement for C style macros either which would be nice, sometimes I'd like to be able to write code like this:

DatabaseStringProperty(DataSet,FieldName1);
DatabaseDecimalProperty(DataSet,FieldName2);
DatabaseStringProperty(DataSet,FieldName3);
DatabaseDecimalProperty(DataSet,FieldName4);

And have the compiler generate a pile of properties with get/set and names that match the fieldname. A partial generic could allow that kind of macro type stuff (You'd probably need the ability to turn a parameter into a string ala the C macro engine # construct).

Perhaps this is just my 1984 C hacker heritage showing through.

hmmm. I meant "live" environment. Not some sort of C# Cybernetics....

Jan

- Covariant return types
- Simplified property syntax with automatic backing store (public property int Foo;)
- Operator constraints for generics

- More flexible interface implementation support. I find the current choice of
either public implicit or private explicit implementation much too limiting. I want to
be able to use any accessibility level I want, and handle multiple interface
methods with the same implementing method.

- Built-in IntPtr arithmetic support. When I brought this up over in Cyrus blog he said it
was more of a BCL feature, but I don't agree. The IL arithmetic opcodes support native int
so I see no reason not to emit them directly, which would require compiler support. To
increment an IntPtr I currently have to write something like
IntPtr p = something;
p = (IntPtr)((long)p + 1);
and it's really ugly ;-), plus it produces unnecessarily bloated IL. It would be much nicer with just
p++;
resulting in a simple add instruction.

- A generic constraint restricting me to unmanaged-types (as defined in A.2 in the spec), so I could use T* in unsafe code.

As Mattias mentioned, Cyrus (http://blogs.msdn.com/cyrusn) took a survey (http://blogs.msdn.com/cyrusn/archive/2004/06/20/160441.aspx) for the Whidbey timeframe. He posted the results (http://blogs.msdn.com/cyrusn/archive/2004/07/06/173822.aspx). Since I'm certain most (if not all) of this wouldn't be implemented for Whidbey, perhaps the results would serve as a good base for further discussion (though some of it *isn't* related to the compiler, much of it is).

Guys, Please give us atleast Comega's Stream, anonymous structs and its cool member access.

If possible give us Spec#'s requires, modifies and ensure (and Boogie)

COmega is a really good start for 3.0. I am going to assume you will get a lot of feedback from the preview - it is very cool stuff, and take what you learn, but better Xml serialization, better DB stuff (bake in everything that you know about how to properly do DB work), and concurrency would be huge.
tools support for this would be crucial, XSDs are still too difficult to create and there should be some easy way to find out the best way to encapsulate concepts in XSD (is your goal object performance?, is it document-centric?, etc.) - whatever we learn from the models that come out of the preview. Concurrency needs some patterns and some wizard support, but poerhaps I am moving too much into BCL, Tools. +1 on the concepts in COmega.

1)
how about replacing

public class MyReallLongAndProperClassName{
public MyReallLongAndProperClassName(){
}
}

with

public class MyReallLongAndProperClassName{
public ctor(){
}
}

or something similar.. this is mainly prompted by classes with overloaded constructors... we have a lot.

2)
this is something you will probably never do but i'd love to see overloaded return types...

I already suggested this in the 'MSDN Feedback Center', (search for the suggestion ID: FDBK11721 ), but I'll repeat it here:

Please allow the 'new()' constraint of generics to take arguments. For instance,

public class MyThing<T> where T: new(string) {...}

would restrict T to types having a constructor that takes a single string as argument. The current solution only allows using a public no-argument constructor with the 'new()' constraint.

The 'new()' constraint seems definitely useful, and people will be lured into adding a 'fake' no-argument constructor to their classes, just to be able to use this C#2.0 feature, adding an 'Initialize(...)' method that passes the arguments that should have been passed to the constructor...

In my experience, such classes tend to cause heavy headaches, because that no-argument constructor creates a partially constructed object, which is an attractive breeding ground for bugs.

I second Mattias on this one:

- Simplified property syntax with automatic backing store (public property int Foo;)

C++ 8 gets this and I think C# should get it too. Especially since the C# compiler does exactly this same thing for "event" fields.

Also, I want more compile-time type safety WRT method attributes. That is, I want to be able to specifiy an additional property on most method attributes called TargetSignature that takes typeof(SomeDelegate). For more info on this see:

http://labs.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackid=3f2c9417-c38b-4388-be71-e69f64f53b9c

Of course, the C# compiler would need to enforce the signature check.

Arha,

You're right, I would expect my example above to print 10 10 times. However, if I replace index with a local, it still prints 10 10 times. That's what I meant to do last night, but I was too tired to think straight.

Traits would be nice.

http://www.iam.unibe.ch/~scg/Research/Traits/

There are a few things I would like to see, though they're not all specific c# language features.

1) Deep marshalling for p/invoke. If you attempt to marshal a structure or class that contains a member that is an array of another structure or class, the marshaller fails. For example, assume you have some structure like Polygon that has a member of type Point[]. This structure will not be marshalled because the member is an array of a non-primitive type.

2) Allow default constructors on structs.

3) Allow pinning of types that contain arrays as members. If I have a type that contains an array of anything as a member, then that type cannot be pinned ( fixed ). Very troublesome in some interop scenarios.

4) Allow multiple, disparate type declarations within a fixed clause. If I have to pin 3 or 4 different types, then all of the nested code is indented *way* too far.

5) Allow for custom aggregate functions or delegates within the System.Data namespace. Today, DataTable supports aggregate functions through Select and Compute methods; however these aggregate functions are "buil-in" and only operate on known primitive types. I would like the ability to bind a data column to some custom type, like Real or Fraction or something, and have a delegate be called when I want to compute the Avg, Sum, Prod, etc of values contained in that column. Also, I would like the ability to write my own aggregate functions as well.

that's all I can think of for now.

I understand that you can change the output directory, but that's only one part of the equation which makes it even more frustrating to me.

Great thread Eric (and fellow readers!).

My 2c worth:

1. Smart inline array creation. Instead of writing this:

myStringArray.Split(new Char[] {'a', 'b'})

I'd like to be able to write this:

myStringArray.Split({'a', 'b'})

(the compiler would need to check the types of all the elements in the "in-line" array, to see that they match (one of) the array types accepted by the method.

2. I'd like to be able to override static methods. For instance, I wanted to set up a number of static classes to cache things. (The first time you call the "Get" method on the cache it retrives the object, and then caches it). The "natural" solution was an ancestor class that defined the basic, thread safe, load-on-demand behaviour, and then derived classes to override the method that actually does the one-off retrieval of whatever it is that you want to cache. Not possible at present tho, since static methods cannot be virtual.

3. A class library request rather than a language one: a "Magic.Empty" class. Instead of writing code like this:

if (myString is null || myString.Length == 0)
OR
if (myArray is null || myArray.Length == 0)

I could write
if (myString == Magic.Empty)
OR
if (myArray == Magic.Empty)

Where Magic.Empty overloads the == operator in such a way that it responds correctly to null arrays and null strings, and to zero length arrays and strings.

4. Speaking of closer integration of C# with databases, I think that there's a lot of handy stuff that can be done with operator overloading in the existing language. In particular, I'd like to be able to write SQL statements in C# syntax. Like this:

Table cust = new CustomerTable();
Table order = new OrderTable();
SqlStatement s = new SqlStatement();
s.Select (cust.ID, order.ID, order.Total);
s.From (cust, order);
s.Where(cust.Class = "Premium " &
order.CustID = cust.ID);

Notice that the where clause is valid C#. Only two tricks are required to make this work: (a) generated classes that define the database structure (my "...Table" classes above) and (b) clever use of operator overloading on those classes, so that when you combine their "field" properties (which are objects too) the result of the expression is an object tree that describes the expression.

That object tree can then be converted to actual SQL as and when required, possibly tailoring the resulting SQL differently depending on what the target database is at runtime. Advantages include compile time checking, intellisense and an all round cleaner approach to SQL. Useful in application server C# coding and in Yukon C# stored procs.

5. Re the request for compiler checking of strings for data binding, I have a suggestion about that on my website. (See URL for this message.) However, what we've found on my current project is that it works almost as well to just generate constants from our datasets, with a little tool we wrote. There's one constant for each column.

I would like to see XPath or OPath support for filtering an object graph or list.

Instead of:
List<int> myInts = new List<int>();
myInts.Add(1);
myInts.Add(2);

int i = 0;
myInts.ForEach(delagate(int a){i+=a;});
Console.WriteLine(i.ToString());

How 'bout:
List<int> myInts = new List<int>();
myInts.Add(1);
myInts.Add(2);

int i = myInts[sum(.)];
Console.WriteLine(i.ToString());

I know this is a really simple example. A good reference for what I am referring to check out <a href="http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnexxml/html/xml03172003.asp">ObjectXPathNavigator</a>.

Re:

if (myString is null || myString.Length == 0)

Whidbey does get this:

if (String.IsNullOrEmpty(myString))

I asked for the same static method to be put on Array but no dice. Not quite as nice as what you suggest but it is better than what we have today (at least in terms of CTS).

Allow delegate for properties. This would allow type safe reflection and databinding.

Change the assembly search order of the compiler.
This maybe already done in version 2 don't know, sorry.

1. Current working directory
2. The common language runtime system directory.
3. Directories specified by /lib.
4. Directories specified by the LIB environment variable.

This makes it a real pain to compile in compact framework assemblies
as the runtime directory always get preference. Having the runtime dir
searched last would make it a lot easier.

Thanks
Bart

I would like to suggest a new custom Attribute type to would be targetted to instrument methods, classes, etc..

For example, we can imagine to deinfe the NonNullableAttribute which is use to tag non-nullable parameters of methods:

[AttributeUsage(AttributeTargets.Parameter,AllowMultiple=false)]
public class NonNullableAttribute : Attribute
{}

and a simple usage of this attribute would be:

public class MyClass
{
public void Method([NonNullable]Object o)
{
// o is non-null;
}
}

Here's a possible implementation: suppose that .NET provides the following custom attribute:

[AttributeUsage(AttributeTargets.Method,AllowMultiple=false,Inherited=true)]
public class ParameterInstrumentorAttribute : Attribute
{}

Our custom attribute class is then modified with it:

[AttributeUsage(AttributeTargets.Parameter,AllowMultiple=false)]
public class NonNullableAttribute : Attribute
{
[ParameterInstrumentor]
public static void Instrument(Object value)
{
if (value==null)
throw new ArgumentNullException(pi.Name);
}
}

The static method Instrumentor would then be injected at the beginning of the MyClass.Method :)

This would mean that we could instrument natively .NET code...

Hi Guys

I really like C# as a language; I believe I'm 20% more productive in it than java. I'd like to see the language keep the things that make it so nice to use, i.e. consistency, clarity of vision, simplicity (small tight language core, first class primitives, two tier learning curve as you can achieve simple things quickly then move onto the more advanced stuff like interop.), and a well balanced tradeoff between language purity and practical considerations. I see a danger in C# evolving into another sprawling C++ monstrocity if it tries to be all things to all people.

With this in mind I thought I could contribute some thoughts on critia which may be useful when selecting new features for the language:

1)Should not modify existing behaviour except when
2)existing behaviour is broken badly (e.g. volatile behaviour was changed in Whideby with the IsVolatile attribute)
3)should not add to the standard library unless unavoidable (these are language features not library features). String and the other dual primitives are a special case, but even so should not be changed unless absolutely necessary. A good degree of decoupling between library and language features is particularly important in the embedded world.
4)should remain pure to the semantics of the language (C# is an strong object model OO language not a scripting language, weak object model language, or a functional language)
5)should simplify the grammer where possible not add additional complexity
6)should improve code clarity not muddy it - a lot of common 'syntactical sugar' abbreviations which save a few keystrokes make code much harder to read. The emerging generations of smart editors (e.g. EMACS;-) will make this sort of thing less important
7)should not detract from machine readability of the source code
8)should not be vendor specific
9)should not be data-store paradigm specific (e.g. no support for in-line SQL which is not capable of also supporting OQL or XQL)
10)should not be hardware platform specific in either bit lengths, pointer assumptions or atomicity assumptions (e.g. operations on 'long' are not atomic on x86 platforms - this is badly broken and exposes underlying hardware semantics to a VM based language!)
11)should not use attributes gratuitously - attributes are annotations, not core language elements
12)should be consistent - the same language construct should behave the same in all cases

I think the Generics changes did a very good job of changing the language in a well thought out and consistent fashion, with one slight issue being the impact on System.* interfaces which break existing code compatibility (IComparable anyone?).

I suggest examining (or writing a program to) a large volume of existing code looking for repeated patterns which can be implemented as language features (e.g. events, delegates, trivial properties)

My personal preference is to leave the language alone as much as possible for the next release and work on tightening up the optimiser and the semantic checks (as several other people have suggested above). Some other minor suggestions: make every tool support piping stdin/out as having to use temp files for ILasm is a pain, support a dump of the internal compiler parse tree a la GCC's intermediate format, improve consistency between C# reflection and ilasm synatax, implement a DFA pass in ILasm to calculate maxstack, properly optimise jump length in ILasm. Generally make it easier to integrate the tools.

Hope this is helpful

Cydergoth
---
The cyder is strong in this one Lord!

Add a language construct to facilitate caching. Caching seems to be one of those areas where the divide between expert and non-expert implementations is severe.
ASP.NET does a very nice job of this, and this is very possibly a BCL request.

On a totally different tack, how about adding some constraint like behaviors to a foreach loop:

foreach( Object o in Objects [where o.ToString() == "MyObject"){}


How about a mechanism for checking parameters (something that is often left out)?

Constraints could be added in a declaration (and collapsed in the editor) throwing accoring to guidelines. I am not knowledgeable enough to know whether or not being a full blown language construct would translate into better static checks or optimizations, but it might.

So, to summarize:
COmega stuff, along with generics (VS2005 makes some huge improvements and it is hard to go back to 2003 to use COmega. I think some of the advances in 2005 tools would make COmega a lot easier.)
Extend the use of [where] to add constraints to foreach constructs, and to add parameter checks to function declarations.


Just throwing stuff out there for you to consider.

I'd like casts from integral to enum types to do an implicit Enum.IsDefined check and throw an InvalidCastException on failure.

This check would not apply to [Flags] enums.

Add-on to the automatic-property discussion: support for the 'readonly' keyword would be great.

And for non-readonly automatic properties, I second the suggestion of firing change-notification events. Maybe a "public string Foo event FooChanged;" syntax, or "... event OnFooChanged()" to call a method (which you would then have to define manually) rather than firing the event directly. Also support for calling a method that takes a single parameter of the same type as the property.

Oh, and virtual constructors and virtual class methods (cf. Delphi) would be really nice.

I snt this a while ago to a microsoftie , but I'll post it again.


I have been playing around with factory paterns lately and I have come
to the conclusion that in general factory patterns are way overrated and
just add another level of complexity to your code - that is until you
need them , but you would have no way of knowing when you need them so
you've got to write a object builder method for each object you create.
And of course this will break your old code that uses direct
instatation.

Here is a suggestion that I have been toying with. Perhaps it is
possible add a static method all "Factorize" or something like that
returns a object. Then you overload the "new" operator to first call
this static method - if this method return a object then you just pass
the method back to the caller, If the method returns null then you
continue with the object creation and instatiaon process.

The advantages would be 2 fold. Simpiler object definition and creation
without having to cross build the factory class and you can selectively
enhance specific objects whn needed. Another advantage is that now all
code written until now has automaticly been Factoryized and if changes
in the object manufaturing process are required you just have to
implemet the static method. This would make singletoning esspecially simple.

One possible problem is that the code might be reentrant if the Factory
method tries to actually create a new object

Please can we have a switch in the ide that ignores case sensitivity and allows me to write CLS compliant case insensitive C# source code ...

I am not to sure if someone else mentioned this, hence, I do not want to be redundant. However, multiple inheritance is something that I think serves a very useful purpose.

Sometimes it woul be great if one could use
decimal x = null;

if( ... )
x = 4;

if( x!=null )
...

deterministic destruction of object(-references) that go out of scope is not available, like in C++.

The caller can use the "using" statement instead, but it still is up to the caller to do so.

My suggestion is to "notify" objects when their reference(s) go out of scope.

E.g.

{
MyInstance i;
...
} // <-- Here, a notification is sent/called for 'i', just right before it goes out of scope.

Maybe through some special interface ("IDisposableNotify") and/or events.

I'd like to be able to use primitives in Generics _with_ support for operators, as in something like

class NumericAlg<T> where T: primitive {
publc T MyAlgorithm(T num1, T num2){
return num1+num2;
}
}

This would help implementing support for numeric algorithms (no need to duplicate the same algorithms different precision types), and make C# a great language for numeric algorithms. Of course, I'd also expect the solution would not loose out on any of the performance benefit compared to writing a specific implementation for each precision.

I also would like to be able to do serious, ML-like functional programming on .NET, but i realize that features like closures, type inference etc. would change c# too dramatically.

my suggestion is: Microsoft leaves c# as an elegant but fairly Conservative imperative language but finally commits itself to supporting ONE functional language? SML.NET is dead, F# seems to be dying, Scheme.net and Haskell.net never got very far despite Microsoft support, Nemerle and Mercury live in small Academic ghettos. <b>PLEASE, Microsoft, give us at least one commercially useful functional language!<b /> We will use it side-be-side with C# and VB and stop asking for functions-as-first-class-values in these languages! :-)

Cheers, Wendelin

I would like to be able to use yield inside an anonymous methods.

i forget typedef (rather atop of the list)

ouf

The ability to specify operator constraints on generics. So I can write generic math functions that work on doubles, ints, and maybe even TimeStamps.

As an old Delphi coder, there are a couple of things I really miss. Typesafe enumerations and sets would be swell. For example, declare this enum:

enum Days {Sunday, Monday, etc... };

In C#, you can assign any integer value at all to a variable of this type:

Days day = (Days)748;

This is meaningless, but valid C# code. (Yes, I can test it with Enum.IsDefined, but I don't want to.) In Delphi, not only can you not assign an invalid int to my variable, I can't assign even a 'valid' int - you *must* use one of the defined enumeration member names, or do an explicit cast (and the assignment above would still fail with an out of range error).

You can also declare a set in Delphi, and use the set to easily test a variable (I am using invented C# syntax):

set of Days WeekendDays = (Saturday, Sunday);
Days day;
// code which assigns a value to 'day'
if (day in WeekendDays) {
// do something...
}

Finally, with an enum in Delphi, you can create arrays with associated values:

string(Days) DayNames = {"Sunday", "Monday", etc...};
string(Days) DayAbbreviations = {"Sun", "Mon", etc...};

You can use these arrays to do simple lookups for text display without case statements (obviously these aren't limited to display text strings, but can be any data type). The array elements cannot be accessed in any way except with the defined enumeration members or an explicit cast (as with the variable assignments described above).

Enough of enums - I have one more thing. Delphi has a "property" keyword which allows you to explicitly define properties and their access methods in a single line of code. For example (again in invented C# syntax):

private int _totalSales;
public property int totalSales get _totalSales set setTotalSales;

This code defines a private member variable, then defines a public property for it. The 'get' accesses the member directly. The 'set' calls the 'setTotalSales' method. This method must be defined separately, and accepts a 'value' parameter of the appropriate type (just like the current C# setter methods). In this scheme, the 'get' and 'set' can each be defined to access the member directly, or call a method. This is really just syntactic sugar, but it seems to me a cleaner, prettier, and easier-to-type way to do it than the current scheme.

1) I'd like the idea of "inline assembly". For example, will be VERY useful when calling OpenGL extensions ( look Tao OGL wrapper for example ). For example:

class CMyClass
{
public void DoSomething ()
{
int i = 0;
i++;
__ilasm
{
blah blah blah....
}
}
}


2) Allow simple "try" blocks. Sometimes you put simply:


class CMyClass
{
public void DoSomething ()
{
try
{
DoOtherThing();
}
catch
{
}
}
}

so it will be to allow the next expression:

class CMyClass
{
public void DoSomething ()
{
try
{
DoOtherThing();
}
}
}

thx

I don't know how involved the Compiler is in the creation of assembly metadata (I'm assuming fairly), but a scenario I come across when making class libraries is maintaining consistant and up-to-date documentation.

Consider the class A:

public class A
{
int x = 0;
///<summary>The X position of A</summary>
public X {get {return x}}

///<summary>My class A</summary>
///<param="aX">The X position of A</param>
public A(int aX)
{ X = aX}

///<param="newX">The X position of A</param>
public DoSomething(int newX, int other)
{...}
}

You can see that I've repeated the comment for variable X throughout the class definition and for more complex classes this situation usually gets worse.

This is a real issue when trying to maintain consistant class documentation, especially when refactoring (thankfully the actual param ids are already refactored along with code in 2005). What I'd imagine is the ability to set up a comment chain through which comment summaries, params etc can be inherited. Perhaps something like:

///<summary>The X value for A</summary>
public int X {get {return x;} }

///<param name="newX" comment="this.X" />
public void Foo(int newX)

Now when the class is compilied the two comments would be identical (I imagine this would use a local copy of the comment for performance).

This could then allow wrapper classes to use internal classes commments for consistancy, and with a little modification also be used for method and constructor overloading.

I'd like to see a raise accessor for events, especially since you guys have already added multiple visiblities for each property accessor. I'd like to write events like this:

public event EventArgs ValueChanged
{
add
{
this.Events.AddHandler(EventKeys.ValueChanged, value);
}
remove
{
this.Events.RemoveHandler(EventKeys.ValueChanged, value);
}
protected raise(object sender, EventArgs e)
{
EventHandler handler = this.Events[EventKeys.ValueChanged] as EventHandler;
if(handler != null) handler(sender, e)
}
}

I think that this has been considered, and I think that somebody added the ability to Mono's compiler at one time (but I'll have to double-check that in a bit). Seeing as IL supports raise accessors and Managed C++ has it, I don't see why C# shouldn't have it. The trickiest part is the syntax for the definition...do you put the argument list again or rely on an implied argument list based on the delegate type? Either way I'd be happy.

Having this feature partially solves the cannot-call-a-null-delegate problem, but more importantly keeps me from having to clutter my class with protected or internal methods for raising events. It's bad enough having a public ValueChanged event and a protected OnValueChanged method, without having to add a protected/internal/whetever RaiseValueChanged method. It'd be more clear to call the exposed event itself when you want to raise it.

hrmm, damn webapp failed and appears to have lost my response.
Anyway, I did add faise support to mono's C# compiler experimentally some time ago. I blogged about it at [1]. The source is both outdated, incomplete, and unreleased, however. I ran into a syntax stumbling box(explained in the blog) that I never finished. There was little interest in it and I had a number of other things to do at the time. At some point in the future I might finish it, if anyone is interested.

1. http://dotnetjunkies.com/WebLog/doconnell/archive/2004/02/01/6412.aspx

I agree they certainly do encapsulate things better into a single construct, however I also realize, as you do, that there are issues that make them difficult in C#.

Over time I prefer the OnXxx method, *HOWEVER*, I don't think that it really deals with all possible situations and I think a combined raise+OnXxx makes more sense. You override OnXxx to handle the event while you override raise to change the way the event is actually raised.

I do think its pretty rare someone would want to change raise semantics but it would certainly make virtual events fesiable and would help with the null check and potentially centralize locking. However I don't think any of these issues are insurmountable with the OnXxx method, just mildy less readable and flexible.

I still stand firm that C# should atleast support *calling* raise methods on events, even if it doesn't support producing them.

Anyway, anymore discussion about this is probably well off topic here. We are already probably flooding Eric with alot more text than he actually wanted. Further responses are (probably) more correctly discussed on my blog post or via email(I'm at onyxkirx at comcast dot net if anyone has any comments to forward).

When multiple teams are involved in development of single assembly, its sometime desired that we have another type of access modifier, using which the team can encapsulate the code, and can enforce that only certain classes (facades) should be used, even internal to the assembly.

public class SomeClass { /* calls FacadesFromTeamA */}
internal class FacadesFromTeamA { /* */ }
friends {FacadesFromTeamA} class TeamAHelper {/* only friend classes can access this class*/}

One thing about Python that is very powerful are the array operators : and -. For instance, to lob off the last character of a string, the expression line = line[:-1] is superior, I think, to line = line.Substring(0,line.Length-1). Other uses of th colon/dash syntax are also very effective. Would it be appropriate to add these overloads to the string class?

It would be nice if the compiler could emit warnings for incorrectly indented source files:

if (expression)
FuncA();
FuncB();
FuncC();

or less obvious:

if (e1)
if (e2)
{
f1();
}
else
f2();

I have found quite common having to read not so good code that just has those kind of bugs, hard to spot when blocks get big. The problem is that the file contains unreliable info (indentation) that humans perceive and rely on but that the machine don't check in any way.

What about pascal style subranges. I HATE having to use (say) a byte when I KNOW in advance that a variable may ONLY take values in the range 0..2.

This probably won't save space, or time but WOULD make a program a fair bit clearer (IMHO).

Some long lead work.

- support putting classes on the stack so they can be cleaned up at the end of function scope
- support true destructors (Deterministic destruction for all languages)
- support specifically deleting objects (can help performance of GC)
- Support multiple inheritance, if needed start with mixins
- Support multiple indexers for C#
- Support an option so that all finalizers can act like critical finalizers or use an attribute to indicate it on the class
rather than requiring deriving from a base class (burning our one base class).
- Fix the Visual Studio IDE so that all items can be configured per build (Debug, Release) for example binary references
- Don't store specific file paths/locations in the .user file that are autogenerated from the projected hint paths ( relative paths were put there originally for a reason)
- Support aspect oriented programming in terms of addition a prolog/epilog to a specific set or all function/method calls
- Option so that shutdown of appdomains and the CLR happen more orderly (proper garbage collection, calling of finalizers, etc.)
- Make it so that Exceptions don't take several seconds to load the first time you hit one.
- The ability to define a conditional during runtime that can conditionally compile out calls to methods during the JIT
(This would allow doing things like adding trace calls at the start of the program but they are effectively compiled out
based on a value in a config file, registry key or config information from a server. This allows for total performance
when needed and adding additional optional tests/checks when you must. An additional cool option would be to allow
swapping methods so that one method is JIT'd under one condition and another under another condition. These options
are great for high performance scenarios where the program must decide which algorithm to use at start up. Allowing
changing and re-JIT'ing at runtime would be ultimately beneficial. This would be a great feature supported by few languages.
Some might say you could use polymorphism to solve this but usually this would mean re-writing a lot of code in
a derived class, especially when we only have one base class now).

- Support dumping full stack information/core like dump loadable my VS.NET to debug customer related problems
- Allow for some safe pointer manipulation without resorting to marking code unsafe
- Allow late bound object access using function names on the object without being required to resort to
Invoke calls. I want to be able to dynamically generate types at runtime and be able to access the object just like
a static assembly - (Obviously only runtime checks for inappropriate method calls would take place). This makes
the value of dynamic assemblies higher.
- The ability to add a function to a class that gets called in the JIT stage as part of building a type that
allows me to add items or change items in my class before the JIT completes.
- Support an MFC like command hierarchy for .NET so we don't have to rebuild the basics of a GUI application each time
or build our own frameworks.
- Support hooking garbage collection getting information about when garbage collection has run and list of all objects
- Support hooking all allocations and de-allocations - sometimes you want some fine control on objects and to keep track
of some objects yourself.
- Build in support to add resources to the .resx xml files so we don't have to resort to sample editors
- Support a default option to copy returned object references that are from a private member of a class to
avoid the problem of exposing private object internals (an encapsulation issue you could Clone if the objects supported
it but many people forget to do this especially people coming from C++)
- Support a friend like class option (possibly with security that allows me to securely link a class to allow access to the internals
of another class (This can be very useful for test classes. Currently it is difficult to write an NUnit test
for checking out classes that store information that you want to test but is not exposed publicly from the class, requiring
use of the internal modifier but then that says the test class must be in the same assembly which is not really acceptable)
- Provide additional easier support in string builder to more easily convert to and from strings so it isn't required
as often to switch between stringbuilder and string
- Allow defining an object that will always be passed with a delegate call (This can allow differentiating which delegate
called a particular method.
- Make it easier to adjust the control ordering in a win form to fix control layout/docking issues
- Supporting adding attribute information to types at runtime
- Do weak references really need to be finalized when the object it was watching gets finalized/de-allocated? Wouldn't an
interface callback be better?
- Support static virtual method so that singleton classes that are derived from a base class, the base class can get
data from the derived class so the base class implementation can make decisions based on the derived class value
An example is a logger class that is singleton and say you want one singletone class to map EventSource1.Log to
a specific category and another singleton derived from the base class that implements Log() to use a different category.
For example say I want a framework log static class to log from framework code (derive from a base that implements log) and
an ApplicationLog static class derived from the same base that logs using the application category.

example (this won't work since both are accessing the same base class variable) and the alternatives currently
require rewriting the base code in the derived class (not a big deal for this sample but if you had a lot of functions
it would be):
public class BaseEventSource
{
static BaseEventSource() {}
protected int _category;
static void Log(string s) { Event(_category,s); }

private Event(int category,string s)
{
Console.WriteLine("Category:"+category+" - "+s);
}
}

public class FrameworkEventSource : BaseEventSource
{
static Framework () {
_category=1;
}

}
public class AppEventSource: BaseEventSource
{
static Framework () {
_category=1;
}

}

//would want calls to use the proper category when called
AppEventSource.Log("Hi");
FrameworkEventSource.Log("Hi");

If we could have a virtual member function for a staticly derived class we could call that function to
get the category id which could be overridden by the derived class

Default parameter syntax. The question of default params has been covered before -- the problem being that the default value is burned into the call site. The stated workaround is to generate overloads.

I understand the problem; it's valid. I understand the solution; it's valid. But don't make me type all those overloads manually! Give me default-parameter *syntax*, but make it *generate* overloads, just as if I had typed all those overloads in longhand. That fixes the versioning problem, but makes way, way less typing (and maintenance) for me. (And lets me share the same XML doc comment between all the overloads, which is also nice.)

I'd like something similar to what Dan, at least a Dan, mentioned above. A cleaner using statement. Currently, if you're using many Disposable objects of different type, there are a lot of nested using statements that make the code look ugly:

using( SqlConnection conn ... ){
using( SqlCommand command ....){
using( StreamWriter r ...){
...
//write to a db and a file
}
}
}

It'd be cool to write one using statement for all of them at once; or as Dan said: put using in front of the declaration.

PingBack from http://paidsurveyshub.info/story.php?title=eric-gunnerson-s-c-compendium-future-language-features-amp-scenarios

PingBack from http://weakbladder.info/story.php?id=3131

PingBack from http://edebtsettlementprogram.info/story.php?id=22179