Features you like added to vb.net, c# or any other .net language.

Compile Checks for;-

Basic Infinite Recursion Detection

This is a example case, i do know how to code it properly.

 Public Function Factorial(ByVal x As Double ) As Double Return X * Factorial(x-1) End Sub

Result:  (Warning / Error) No base case detected, which would result in a stack overflow.

Simple Infinite Loops Detection

Dim x As Integer Dim OutputText While x<InputText.Lenght x = 0 OutputText &= Chr(Asc(InputText(x)-2) x +=1 End While

Possible Detection Rules (Partial Solution to Halting Problem)

No Exit While inside of while loop

No If statements who results affect variable x inside while loop.

X is set to a value >= InputText.Lenght smallest possible value of 0

Result: (Warning / Error) Possible Infinite loop.

Any other language / compiler features you like see added.

Simplying the C# switch statement would be nice, the 'break' statement is redundant.

But don't we have these threads all the time thesedays?

W3bbo said:

Simplying the C# switch statement would be nice, the 'break' statement is redundant.

 

But don't we have these threads all the time thesedays?

Is break redundant? Does the C# switch statement support multiple cases like VB's does? Otherwise, I'd still want the power to fall down into the next case.

Select Case someFlag

   Case specialFlag

      'some code

   Case normalFlag, otherFlag

      'other code

End Select

switch(someFlag)

{

   case specialFlag:

      //some code

      break;

   case normalFlag:

   case otherFlag:

      //other code

      break;

}

.NET 4.0 will have code contracts, that will negate some of your issues. That and Pex will resolve a lot of these issues, that are more user error focussed features than langauge improvements per se

spivonious said:

W3bbo said:

*snip*

Is break redundant? Does the C# switch statement support multiple cases like VB's does? Otherwise, I'd still want the power to fall down into the next case.

 

 

Select Case someFlag

   Case specialFlag

      'some code

   Case normalFlag, otherFlag

      'other code

End Select

 

switch(someFlag)

{

   case specialFlag:

      //some code

      break;

   case normalFlag:

   case otherFlag:

      //other code

      break;

}

Yes you can drop down, but I don't think I've used default in 5 years of C#

There are static analysis tools (that run pre-compile phase) that are programmed to find thousands of errors like that, even more that aren't really trivial. Coverity is probably the biggest vendor in this arena, and their tool supports C#.

vesuvius said:

spivonious said:

*snip*

Yes you can drop down, but I don't think I've used default in 5 years of C#

I use default: for dealing with unexpected enum values.

I'd like to see the introduction of String Enums and possibly Java-style enumerations, except without the boneheadness.

W3bbo said:

vesuvius said:

*snip*

I use default: for dealing with unexpected enum values.

 

I'd like to see the introduction of String Enums and possibly Java-style enumerations, except without the boneheadness.

W3bbo, can you explain why string enums would help you? I thought the whole point of enumerations was to remove the actual value from the equation.

W3bbo said:

vesuvius said:

*snip*

I use default: for dealing with unexpected enum values.

 

I'd like to see the introduction of String Enums and possibly Java-style enumerations, except without the boneheadness.

I add that as an enumeration, i.e.

enum Fruits{

Unknown = 0,

Apples,

Oranges,

Lemons,

Bananas

};

spivonious said:

W3bbo said:

*snip*

W3bbo, can you explain why string enums would help you? I thought the whole point of enumerations was to remove the actual value from the equation.

String enumerations are good for things like LookupPrivilegeValue which expects a string privilege name from a known set. I use a static class filled with const string members right now.

Extension properties in C#.

W3bbo said:

spivonious said:

*snip*

String enumerations are good for things like LookupPrivilegeValue which expects a string privilege name from a known set. I use a static class filled with const string members right now.

I'm not sure I fully follow your example. Why would LookupPrivilegeValue expect a string privilege name instead of an enumeration value? Not to mention there's ways to convert a string to/from an enumeration value, so there should be a way to do what you want there without a "string enumeration".

As for the original idea: that's not a language change. Note that the code didn't change in any way. That's a compiler change. Compilers are free to report any diagnostics they want to, generally.  I assume the C# standard provides the same leeway that the C++ standard does (you can produce any warnings you want to for what ever you want, but only the errors specified by the standard). That said, it's not a good idea to produce such diagnostics by the compiler. This adds significant compilation overhead, which is detrimental to the development process. This is the sort of thing you want to see in static analysis tools instead. Microsoft provides such a tool in FXCop or Code Analysis within VisualStudio. I don't believe there's a rule for either of these, but the rules can be added.

I'd love to see Java-style enums added to C#.

W3bbo said:

spivonious said:

*snip*

String enumerations are good for things like LookupPrivilegeValue which expects a string privilege name from a known set. I use a static class filled with const string members right now.

You do know you can just use ToString() on an enum to get it's value in string form?

• Extension Properties 
• Mixins
• Language support for tuple types:
  

  public (int, string) GetSomeTuple() { /* ... */ }

  Perhaps this could even extend to tuples with named properties (much like anonymous types):
  

  public (int Age, string Name) GetSomeTuple() { /* .. */ }

• Better language support for function types (unlimited args, named args)
• More type inference! this leads to my final request...
• Better support for anonymous types (shouldn't be limited to only a local scope):
  

  public anonymous GetSomeObject() { return new { Feature = "Anonymous Types", Version = 2 } }

  
  Still strongly typed, just a lot simpler.

@AndyC

"You do know you can just use ToString() on an enum to get it's value in string form?"

That's true, but the naming rules for enums don't capture all of unicode  

ktr said:

I obviously don't expect all of this, but it would be nice.

• Extension Properties 
• Mixins
• Language support for tuple types:
  

  public (int, string) GetSomeTuple() { /* ... */ }

  Perhaps this could even extend to tuples with named properties (much like anonymous types):
  

  public (int Age, string Name) GetSomeTuple() { /* .. */ }

• Better language support for function types (unlimited args, named args)
• More type inference! this leads to my final request...
• Better support for anonymous types (shouldn't be limited to only a local scope):
  

  public anonymous GetSomeObject() { return new { Feature = "Anonymous Types", Version = 2 } }

  
  Still strongly typed, just a lot simpler.

It seems a lot of what you desire is in F#, why don't you use that instead? The type inference in the language is sublime.

let x = y 
let apples = oranges 

I now use the var keyword in C# like its running out of fashion. In visual basic you have

Dim anInt as Integer 

which is far more elegant than

MyClass myClass = new MyClass();

vesuvius said:

ktr said:

*snip*

It seems a lot of what you desire is in F#, why don't you use that instead? The type inference in the language is sublime.

 

let x = y 
let apples = oranges 

 

I now use the var keyword in C# like its running out of fashion. In visual basic you have

 

Dim anInt as Integer 

 

which is far more elegant than

 

MyClass myClass = new MyClass();

Visual Basic 9 also has type inference.

In C# you can do:

var x = 42;

And in VB you can do:

Dim x = 42

In both cases the type is inferred to be an integer. However, VB will only do that if Option Infer is turned on (which I think is the default for new projects in VS2008); if Option Infer is off, it uses the old behaviour in which case x will be a late-bound Object in the above example.

It also has the strange effect that in VB, the following three lines are now identical in meaning (with Option Infer On):

Dim foo As New MyClass()
Dim bar = New MyClass()
Dim baz As MyClass = New MyClass()