What would you say is the biggest error they made, in either including, implementing or omitting a feature?

http://oredev.org/2010/sessions/c-s-greatest-mistakes

Of course, this isn't stricly about C# as the runtime itself didn't support generics at that time...

22 minutes ago, Dexter wrote

I think the biggest mistake was the initial release of C# without generics. The traces of the old, non-generic, interfaces, delegates, collections etc. are visible to this day in both user written code and the .NET Framework library.

Of course, this isn't stricly about C# as the runtime itself didn't support generics at that time...

I don't know, the non-generic things like ArrayList and non-typed collection interfaces are useful, so the only problem is the inconsistency in naming (e.g. why isn't it ArrayList<T> instead of List<T> ?) and also namespaces (it would be better if the generic collection types were under System.Collections rather than System.Collections.Generics).

Now, the existence of the non generic collections is not a big issue. The problem is with framework APIs that are still using non generic interfaces (see for example the PropertyDescriptorCollection in System.ComponentModel which implements IList & co.)

PS: AFAIK "Array" was dropped from List<T> because it unnecessarily exposes an implementation detail (a list is implemented by using an array).

Yes, the non generic collections can be useful sometimes but in many (all?) cases you can achieve the same results by using a generic collection with an object type argument (List<object>  for example).

Now, the existence of the non generic collections is not a big issue. The problem is with framework APIs that are still using non generic interfaces (see for example the PropertyDescriptorCollection in System.ComponentModel which implements IList & co.)

I'd like to see .DataSource properties (typed as Object) replaced with a more stronger-typed alternative. The documentation lists what interfaces are accepted, so why not put that in the code?

2 hours ago, Dexter wrote

Yes, the non generic collections can be useful sometimes but in many (all?) cases you can achieve the same results by using a generic collection with an object type argument (List<object>  for example).

Now, the existence of the non generic collections is not a big issue. The problem is with framework APIs that are still using non generic interfaces (see for example the PropertyDescriptorCollection in System.ComponentModel which implements IList & co.)

PS: AFAIK "Array" was dropped from List<T> because it unnecessarily exposes an implementation detail (a list is implemented by using an array).

How would you explain LinkedList<T>?

22 minutes ago, Bass wrote

*snip*

How would you explain LinkedList<T>?

I believe that class/struct names should reflect their implementation concept/theory, but that interface types shouldn't. That isn't the same thing as "exposing implementation details" like fields.

If you ask me, this "exposes implementation detail" is a bit pompous. They also changed Hashtable to Dictionary but it's not like you can hide the fact that the Dictionary uses a hashtable internally. You have to document the fact that it requires GetHashCode to work properly, so much for hiding implementation details...

29 minutes ago, W3bbo wrote

*snip*

I believe that class/struct names should reflect their implementation concept/theory, but that interface types shouldn't. That isn't the same thing as "exposing implementation details" like fields.

I don't really agree with hiding implementation details for collections either. It's very important for the consumer of the collection to know if a list uses a linked list or array, because the difference in algorithmic complexity between the data structure operations could mean order of magnitude(s) worse performance depending on how they are used.

• More of the .NET thing, but the prefixing of the interfaces with "I". Just looks ugly to me, and I think it discourges use of interfaces when they really should be used (I don't see IList used so often, even though "List" is an implementation I've seen methods that only accept it).
• As we were talking above, I think the collections in .NET are generally poorly designed.
• The C++ syntax for class inhertence. It makes sense in C++ because there is no language distinction between interface and class. They should have taken Java's syntax for this.
• Multiple language features that do similar (or even the same thing). One example: lambda vs anon functions.
• LINQ-to-Objects. Some people seem to thing it looks fancy in code (I guess?), but I don't think it makes the code any clearer then a simple foreach loop (which tends to be faster anyway). See above also.

array on stack and array embedded/inlined in struct
indexed property
event assigning in the object initializer block
more flexible and powerful generics type parameter constraints, like valuetypes and math operators

public extension class SomeExistingClass
{
    // Add whatever instance or static methods you want
    // Add any properties you want
    // You can't add any new fields though...results in compiler error
}

The compiler should then impose extension-specific limitations, like the fact that you can't add new fields, but you are now free to add new methods and properties using the exact same syntax that we are already familiar with.

The advantage here is that there is nothing new that the developer needs to learn other than how to spell "extension". No more weird static methods with the first "this" parameter, full support for properties and static methods, etc.

EDIT: Oh, and for value types, the "this" parameter should be a ref to the original struct, not a copy of it. Yes, there really are cases where you want to change just one or two values in a struct for performance reasons (see the XNA Matrix class, which consists of 64 bytes and is used in tight loops in 3D games. The existing extension mechanism forces two full copies of a value type if you need to return a modified version of it).

CLARIFICATION: It seems some people think I'm implying that the class you are extending has to be within the same namespace as the original class. This is not true and this is never what I proposed. The class can be in any other namespace, just like extension methods right now can be in any other namespace. If there are name collisions, you would need to qualify the class you are extending exactly like you would need to qualify it right now with the existing extension mechanism.

Also, I'm not proposing that the compiler use the exact same restrictions as that of a "partial" class. It is merely a way to demonstrate that there is precedent for similar syntax elsewhere. An extension class will come with its own set of restrictions, and the compiler will enforce those  restrictions. For instance, you would not be able to add new fields etc.

But other than that C# is one of my favorite languages!

5 hours ago, Bass wrote

Generally speaking C# is a good language. I don't know what would be the worst things, but this is what I don't like.

• More of the .NET thing, but the prefixing of the interfaces with "I". Just looks ugly to me, and I think it discourges use of interfaces when they really should be used (I don't see IList used so often, even though "List" is an implementation I've seen methods that only accept it).
• As we were talking above, I think the collections in .NET are generally poorly designed.
• The C++ syntax for class inhertence. It makes sense in C++ because there is no language distinction between interface and class. They should have taken Java's syntax for this.
• Multiple language features that do similar (or even the same thing). One example: lambda vs anon functions.
• LINQ-to-Objects. Some people seem to thing it looks fancy in code (I guess?), but I don't think it makes the code any clearer then a simple foreach loop (which tends to be faster anyway). See above also.

The IInterface thing is from COM, but I prefer it because often you have types and related interfaces that should have the same name, but without the I prefix you'd get a collision. It is interesting how it's the single exception from the "strictly no hungarian" rule in .NET.

It also makes it possible to glance at a type definition and see what types it extends vs what interfaces it implements.

I wouldn't say they do the same thing: Lamba functions are an application of anonymous methods (and as far as CIL is concerned, they're the same thing). It's like saying we shouldn't have verbatim "@" strings because you can express their contents as regular strings.

Linq-to-Objects is meant for complicated in-memory object graphs. Outside of data access (which we've got Linq-to-Sql for anyway) I can't see many applications. Maybe in massive data visualisation, but I've seen more people abuse it or make something overly complicated.

5 hours ago, felix9 wrote

personally I want:

array on stack and array embedded/inlined in struct
indexed property
event assigning in the object initializer block
more flexible and powerful generics type parameter constraints, like valuetypes and math operators

You can already do array-on-stack using the stackalloc keyword and struct arrays with the fixed keyword. The only catch is it's got to be within an unsafe context. For example:

unsafe struct Foo {
    public fixed char[128];
    public static Bar() {
        int* baz = stackalloc int[ 512 ]; // create a 512-element sized array on the stack, it does not need to be freed
    }
}

indexed properties... they already exist with the 'this' property, so what you're actually after is named indexed properties. The thing is that such a system would conflict with the current 'this' property (e.g. what happens if a named-indexed-property returns an object with a 'this' property?).

5 hours ago, BitFlipper wrote

I think the way they implemented extension methods is too limited, convoluted and broken. There is a much cleaner and easier way. They should have used the same concept as a "partial" class, and implemented extension methods like this

I agree, but that approach doesn't lend itself to making lots of extensions for a large number of types, as you have to create a new type for each of them (even if you're only adding a single new member).

An advantage of the 'extension class' approach is you can now have extension properties (without any weird convulted syntax).

The language designers could add both approaches, but then they'd get shot down for language bloat. I guess we're stuck.

No opt-in policy for nullness (Maybe<T>), except for structs via Nullable<T>
No opt-in policy for mutability (classes, structs)
No recursive enumerations (datatype constructors) or pattern-matching
No generic numerics
No kind-system

Hmm's:

Slow linq to objects, unsuitable for fundamentalists (iterators don't mesh well with recursive use/structures.)
Partial classes and extension methods - not as holistically designed as one might wish

Symptoms of a 10 year old language and runtime.

Dispite all this it's still a great language.

PS - language doesn't need runtime just to support generics - look at Java. Bracha et al made generics via type-erasure (don't like it due to performance, but it shows its possible.)

I mean, it isn't as if your current projects automatically starts using the latest .Net version without your control. You usually have to tweak a project anyway when you switch .Net versions, so I don't think it is such a bad thing.

This will ensure that the language doesn't get too bloated just for the sake of backwards compatibility when there are new/better ways to do the same thing.

That was C#'s greatest mistake.

I have to say I think code is eminently more readable when you have a .Any(a=>) or .All(a=>) or .Skip(a=>). IF you work with low level image or video processing, you typically end up with several nested for loops and a state machine (it is never a simple for loop) just to express the standard sequence operators. When you add this code plus the complex maths and protocols in the code anyway, anything that increases readability is a Godsend.

That is singularly the greatest addition to C# in my opinion. If people have issues with performance then use C++ but I use them in pretty hardcode situations, where the customer complains abaout any slowness, and they are still quick

18 hours ago, W3bbo wrote

I agree, but that approach doesn't lend itself to making lots of extensions for a large number of types, as you have to create a new type for each of them (even if you're only adding a single new member).

An advantage of the 'extension class' approach is you can now have extension properties (without any weird convulted syntax).

The language designers could add both approaches, but then they'd get shot down for language bloat. I guess we're stuck.

Do you really think the following is too verbose? It looks pretty clear and concise to me. It only adds three total extra lines for each type you want to extend.

public extension class SomeExistingClass
{
    public string DoSomethingNew()
    {
        //...
        return result;
    }
}

Yes true, but you have to agree that the way extension methods have since been used and abused in cases that have nothing to do with LINQ just shows that it is something that a lot of people want to use, and obviously find that it is useful to them.

I'm just suggesting a way to clean it up and make it more consistent with the rest of the language (we all know how partial classes work). The current extension syntax is convoluted and limiting and doesn't seem to fit in with the rest of the language (it seems contrived to me).

17 hours ago, vesuvius wrote

@Bass:LINQ-to-Objects. Some people seem to thing it looks fancy in code (I guess?), but I don't think it makes the code any clearer then a simple foreach loop (which tends to be faster anyway). See above also.

I have to say I think code is eminently more readable when you have a .Any(a=>) or .All(a=>) or .Skip(a=>). IF you work with low level image or video processing, you typically end up with several nested for loops and a state machine (it is never a simple for loop) just to express the standard sequence operators. When you add this code plus the complex maths and protocols in the code anyway, anything that increases readability is a Godsend.

That is singularly the greatest addition to C# in my opinion. If people have issues with performance then use C++ but I use them in pretty hardcode situations, where the customer complains abaout any slowness, and they are still quick

I think normal code tends to be far more readable then complex LINQ or SQL statements.

Sorry I don't understand why there would be any such a limitation. Why can the compiler create extension methods right now without the code being in the same namespace, but won't be able to do essentially the exact same thing but with only syntactic differences from the current implementation? What technical reason do you foresee that would require the extension class to be in the same namespace as the original?

EDIT: I suspect you are thinking too much about how partial classes work. It doesn't mean the same restrictions need to apply to extension classes as those that do to partial classes. They would be different concepts, each with their different set of restrictions. The namespace restriction doesn't need to apply at all to extension classes, just like they don't apply to extension methods right now.

namespace Foo
{
  public extension class String
  {
  }
}

How would the compiler know that the extensions are for System.String and not for Other.Namespace.String?

public extension class System.String

Evil variant for those who can stand the syntactic similarity but different interpretation to an unspecified foreign language entity

public class String extends System.String

How does the compiler know which class to extend with the current extension syntax?

2 hours ago, BitFlipper wrote

@Sven Groot:

How does the compiler know which class to extend with the current extension syntax?

The class' type is specified as a parameter to the method, so the type name just needs to be qualified as such:

using MyNamespace1;

namespace MyNameSpace2 {

public static class Extensions {

public static void MyExtensionMethod(this MyClassInNamespace1 item) {

}

}

}

Correct, I'm just trying to understand the problem that Sven identified.

I am sure C# is some short coming, but, I cannot remember what they are, which is a good thing. Meaning it is not pissing me off enough for me to remember.

Abusing C#

I know I'm going to be rewriting some experimental code based on this at least.

1 day ago, BitFlipper wrote

@W3bbo:

Correct, I'm just trying to understand the problem that Sven identified.

The 'partial' type syntax doesn't give you any way to say I want to extend a class from namespace A and I want the extension to be in namespace B. Which is basically an essential feature if you don't want to risk name collisions.

It also creates a possibly awkward problem that you'd need to support properties extensions, operator extensions, event extensions and pretty much anything else you can think of that could be defined in a class extensions, or else the syntax will seem jarring (why does turning this into an extension suddenly break X, Y and Z)

5 hours ago, AndyC wrote

The 'partial' type syntax doesn't give you any way to say I want to extend a class from namespace A and I want the extension to be in namespace B. Which is basically an essential feature if you don't want to risk name collisions.

But it does. In the example I posted the extension exists in MyNamespace1, but the class to be extended exists in MyNamespace2.

2 hours ago, W3bbo wrote

*snip*

But it does. In the example I posted the extension exists in MyNamespace1, but the class to be extended exists in MyNamespace2.

Yes, but your example is how the real thing works and not the way BitFlipper was proposing it should have been done.

Bass' suggestion is probably closer to what you'd have to do, but it looks wrong and too easily confused with inheritance.

9 hours ago, AndyC wrote

*snip*

The 'partial' type syntax doesn't give you any way to say I want to extend a class from namespace A and I want the extension to be in namespace B. Which is basically an essential feature if you don't want to risk name collisions.

I just left out the namspace because I thought it was kind of obvious that you can resolve name collisions in exactly the same way you do right now with the current extension mechanism (or anywhere else in .Net for that matter). If the compiler complains about a name collision, simply add the namespace in front of the class you are extending. Why is this suddenly such a big problem?

It also creates a possibly awkward problem that you'd need to support properties extensions, operator extensions, event extensions and pretty much anything else you can think of that could be defined in a class extensions, or else the syntax will seem jarring (why does turning this into an extension suddenly break X, Y and Z)

The compiler will prevent you from doing things that don't make sense within the context of the extension class, like trying to add new fields, etc. How would this be any more "jarring" than what we have right now? Even if it only allows new methods and properties, it would already be an improvement over what we have now, and the syntax would be much less jarring than the current extension syntax.

If you look at the "partial class" documentation, it lists a set of restrictions, and the compiler will let you know when you don't follow those restrictions. Why can a different set of restrictions not be applied in the case of an extension class? We aren't talking about just allowing you to add "extension" before a class, instead this is about adding new functionality to the compiler so that it is fully aware of such a new extension mechanism and its restrictions.

There is also the question of what the extension class would then actually be called (so that languages that don't support extension methods can access them as regular static methods), and how to deal with the possibility of the this parameter being null. For the latter, it seems it would be easy to say that you can just have the compiler insert a null check before calling the extension method, just like the JIT does for regular methods. But, again we must remember that extension methods are actually static methods and can be called as such, and in that case there's nothing stopping you from passing null, which the method would then not be prepared to handle. You can get around that by making extension methods a CLR feature, but then .Net 3.5 would not have been able to run on the 2.0 CLR.

The null issue can be gotten around I guess by simply saying that in extension methods, this can be null, but it does feel a bit weird.

How about this alternative:

static class Extensions
{
  public static void System.String.DoSomething(int x) { }
}

It's similar to the syntax used for explicit interface implementations, so it has precedent. Though admittedly it does also suffer from the "this can be null" issue.

I'm a little bit unsure as to why you are trying to overcomplicate things. What I am proposing is changing...

public static class MyExtensions
{
    public static int WordCount(this System.String str)
    {
        // ...
        return wordCount;
    }
}

... to ...

public extension class System.String
{
    public int WordCount()
    {
        // ...
        return wordCount;
    }
}

It is merely a syntax change in how you write extensions to classes. Internally the compiler treats it exactly the same as it does right now, and emits exactly the same MSIL. Why would there suddenly be this list of new technical hurdles that do not exist in the current implementation?

How does the current implementation deal with the "using" statement? How does the current implementation deal with a null this parameter? There are you answers.

A long time ago there was a thread on C9 about missing extension properties, and IIRC, the reason given that there aren't any extension properties was that they could not come up with a satisfactory syntax for it. With the proposed syntax, it would be possible to add extension properties (and any other class features that make sense in the context of an extension class) in a known and familiar way that doesn't feel as contrived as what it apparently needs to be if it had to be added to the existing extension mechanism.

In addition, the properties will just be compiled to the get_ and set_ methods anyway, so there should not be any problem with properties in this case either since the syntax issue with the current mechanism would be resolved.

Can you clarify what the big problem is in this case?

Also note that extension methods can safely deal with nullness, which can be an asset, not a problem: consider this: string.IsNullOrWhitespace(myStr) vs myStr.IsNullOrWhitespace().

The instance method cannot check for the presence of this-nullness (although that could be a neat feature to contemplate) but if IsNullOrWhitespace is an extension method it is entirely safe and in this case part of the job of the method to check for nullness.

The general problem of nullness is not solved with extension methods but since all extension methods must deal with it anyway, in one way or another, it doesn't get worse either.

class Foo // this is the name of the class; it is scoped strictly
          // to the current namespace and cannot be fully qualified
{
  public static int SomeMethod()
  {
    return this.Something; // this is guaranteed not to be null
  }
}

Now look at your syntax:

extension class Foo // this is the no longer the name of the class (what would be?);
                    // it refers to a class in a different namespace but defines
                    // one in the current namespace and can suddenly be fully
                    // qualified, even though you can not normally do that in this context.
{
  public static int SomeMethod()
  {
    return this.Something; // this can suddenly be null
  }
}

This hypothetical "extension" keyword changes the meaning of the name and the semantics of the method in a way that is inconsistent with how the language works elsewhere.

By comparison, the actual current syntax doesn't change the meaning of a class declaration statement, and it makes it explicit that, regardless of how it may be invoked, the parameter that takes on the role of "this" is still a regular parameter and can therefore be null so you should check that and throw an ArgumentNullException if necessary.

Yes I see your point but why can't the compiler insert a null check before you even enter the extension method, just like it happens right now with regular methods? So if I have:

string someString = null;
someString.ToLower();    // <- NullReferenceException

So if I do the same for an extension method, I should get:

string someString = null;
someString.MyExtensionMethod(); // <- NullReferenceException

The way the current extension methods work is the one that has the problem with expectation. This is actually another opportunity to clean it up and make extension methods more consistent with regular methods and remove the problem with expectation that extension methods created in the first place.

Here is an example from Ruby:

http://donttrustthisguy.com/2005/12/31/ruby-extending-classes-and-method-chaining/

Right now the compiler/IDE does everything it can to make extension methods appear like regular methods. Why is it doing that? The way it is currently implemented, it can't get there all the way. Why not go all the way and truly make them feel and act like regular methods? Are we so used to the discrepancies and limitations at this point that we should try and maintain the status quo? Or is there a use case where they are required to be as wonky as they are right now?

Also, why does extension methods need to feel and act like static methods at all? Isn't that just a side-effect of how the current implementation works? You can even go so far and say that if you want a static method, you can use the "static" keyword just like you can with a regular method and it will feel and act just like a regular static method.

EDIT: Obviously the compiler is well aware of extension methods as it currently implemented. Before extension methods were added, the same code would have refused to compile (what is this "this" thing before the type in the parameter list?). My point is that the compiler is already involved. I don't think the compiler support to make this suggestion work is necessarily much more complicated, just different. Yes I think there will probably be some more work for the compiler but the benefits of more consistency, familiarity for developers and new opportunities to add features like properties without contrived syntaxes outweigh the added complexity.  

Unless of course you want that check to be added in the extension method itself, which is against going against expectation (slightly) because that's not where you'd expect the NullReferenceException to be thrown.

And then there's languages  that don't have any syntax for extension methods (like VB). They can still declare them by decorating a method with the ExtensionAttribute, but of course the compiler won't add any extra stuff in those cases.

Your syntax has merits, but I just feel it introduces too many corner cases and goes against how the language normally works in too many places. The only real way to get around that is to make extension methods a CLR feature rather than purely syntactic sugar.

This would have solved problems such as the original IClonable interface problem. If I clone a Foo derived from ICloneable, the method Foo.Clone override could return a Foo instead of an Object, without needing to use a generic interface. When working with an instance typed as Foo, you would not need to downcast the returned clone as a Foo.

Because it introduces new problems such how to do overloaded methods, it is a fundamental aspect of a type system that has to be figured out before a language is designed. I think it would have been a better type system, closer to the type hierarchy as described in the original Liskov "Abstraction and Specification in Program Design".