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.

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;

}

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#

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.

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.

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.

"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()

// public virtual SampleObject(string name)  {  }

Virtual static methods.

// public static virtual DoSomething() { }

Virtual static constructors.

 // public static virtual SampleObject(string name)  {  }

Enumeration set operations.

// textBox.Anchors += { AnchorStyles.Right, AnchorStyles.Bottom };

Implementation through delegation.

// public class SomeItems : IList<SomeItem> { private List<SomeItem> items; private implements IList<SomeItem> GetList() { return items; }  }

Static method extensions.

// public static void DoSomething(this SomeType, string message);

Property extensions.

// public string FunnyName { this SomeType; get; set; }

Static property extensions.

// public static string FunnyName { this SomeType; get; set; }

Type aliases.

// public typedef SomeItemList = List<SomeItem>;

Expando properties and methods.

// instance.SomeNewProperty = 12; instance.SomeNewMethod = (string message) => MessageBox.Show(message);

Class references.

// public SomeItemClass = class of SomeItem;

Message based dynamic methods.

// public message(1) void DoSomething(ref MessageArgs messageArgs) { }

sysrpl said:

Virtual constructors.

// public virtual SampleObject(string name)  {  }

 

Virtual static methods.

// public static virtual DoSomething() { }

 

Virtual static constructors.

 // public static virtual SampleObject(string name)  {  }

 

Enumeration set operations.

// textBox.Anchors += { AnchorStyles.Right, AnchorStyles.Bottom };

 

Implementation through delegation.

// public class SomeItems : IList<SomeItem> { private List<SomeItem> items; private implements IList<SomeItem> GetList() { return items; }  }

 

Static method extensions.

// public static void DoSomething(this SomeType, string message);

 

Property extensions.

// public string FunnyName { this SomeType; get; set; }

 

Static property extensions.

// public static string FunnyName { this SomeType; get; set; }

 

Type aliases.

// public typedef SomeItemList = List<SomeItem>;

 

Expando properties and methods.

// instance.SomeNewProperty = 12; instance.SomeNewMethod = (string message) => MessageBox.Show(message);

 

Class references.

// public SomeItemClass = class of SomeItem;

 

Message based dynamic methods.

// public message(1) void DoSomething(ref MessageArgs messageArgs) { }

instance.

Virtual constructors.

// public virtual SampleObject(string name)  {  }

What would that even do? You must invoke a constructor with an explicit type name (new Foo()), how would a virtual constructor even work? There's no vtable you can use yet. This is pointless.

Virtual static methods.

// public static virtual DoSomething() { }

Same problem. Static methods are always invoked with a type name, not an insance, so no vtable, so no way to figure out which overridden method to use. Also pointless.

Virtual static constructors.

 // public static virtual SampleObject(string name)  {  }

This one doesn't make any sense whatsoever, not from a technical point of view, and I don't see what kind of scenario they would enable even if it were possible, which it isn't.

Enumeration set operations.

// textBox.Anchors += { AnchorStyles.Right, AnchorStyles.Bottom }; 

Is doing "textBox.Anchors |= AnchorStyles.Right | AnchorStyles.Bottom;", which has the same effect, really so much harder?

Implementation through delegation.

// public class SomeItems : IList<SomeItem> { private List<SomeItem> items; private implements IList<SomeItem> GetList() { return items; }  }

Sounds intriguing. It's essentially aggregation, although you would need to have a way to at least provide some of the methods yourself, otherwise there's not much point in aggregating in the first place.

Static method extensions.

// public static void DoSomething(this SomeType, string message);

Could be useful if only to provide context for some methods. However, the syntax you give here is identical to that of regular extension methods (which are static methods on the class that defines them), and the use of the word "this" is confusing since static methods have no this pointer.

Property extensions.

// public string FunnyName { this SomeType; get; set; }

Agreed. Note they are technically supported in IL, there's just no syntax for them yet.

Static property extensions.

// public static string FunnyName { this SomeType; get; set; }

Same argument as static extension methods: don't use the keyword this.

Type aliases.

// public typedef SomeItemList = List<SomeItem>;

Could be useful, but can also be confusing.

Expando properties and methods.

// instance.SomeNewProperty = 12; instance.SomeNewMethod = (string message) => MessageBox.Show(message);

How Javascript.

Class references.

// public SomeItemClass = class of SomeItem;

 

Message based dynamic methods.

// public message(1) void DoSomething(ref MessageArgs messageArgs) { }

sysrpl said:

Virtual constructors.

// public virtual SampleObject(string name)  {  }

 

Virtual static methods.

// public static virtual DoSomething() { }

 

Virtual static constructors.

 // public static virtual SampleObject(string name)  {  }

 

Enumeration set operations.

// textBox.Anchors += { AnchorStyles.Right, AnchorStyles.Bottom };

 

Implementation through delegation.

// public class SomeItems : IList<SomeItem> { private List<SomeItem> items; private implements IList<SomeItem> GetList() { return items; }  }

 

Static method extensions.

// public static void DoSomething(this SomeType, string message);

 

Property extensions.

// public string FunnyName { this SomeType; get; set; }

 

Static property extensions.

// public static string FunnyName { this SomeType; get; set; }

 

Type aliases.

// public typedef SomeItemList = List<SomeItem>;

 

Expando properties and methods.

// instance.SomeNewProperty = 12; instance.SomeNewMethod = (string message) => MessageBox.Show(message);

 

Class references.

// public SomeItemClass = class of SomeItem;

 

Message based dynamic methods.

// public message(1) void DoSomething(ref MessageArgs messageArgs) { }

instance.

Type aliasing has been in C# since the beginning.

using StringList = System.Collections.List<System.String>;

the only problem with the syntax is that unless a type is specified with a keyword (string/int/etc) you must use the full type name, which gets tedious after a while. I'd prefer it if it respected existing namespace imports to resolve type names.

sysrpl said:

Virtual constructors.

// public virtual SampleObject(string name)  {  }

 

Virtual static methods.

// public static virtual DoSomething() { }

 

Virtual static constructors.

 // public static virtual SampleObject(string name)  {  }

 

Enumeration set operations.

// textBox.Anchors += { AnchorStyles.Right, AnchorStyles.Bottom };

 

Implementation through delegation.

// public class SomeItems : IList<SomeItem> { private List<SomeItem> items; private implements IList<SomeItem> GetList() { return items; }  }

 

Static method extensions.

// public static void DoSomething(this SomeType, string message);

 

Property extensions.

// public string FunnyName { this SomeType; get; set; }

 

Static property extensions.

// public static string FunnyName { this SomeType; get; set; }

 

Type aliases.

// public typedef SomeItemList = List<SomeItem>;

 

Expando properties and methods.

// instance.SomeNewProperty = 12; instance.SomeNewMethod = (string message) => MessageBox.Show(message);

 

Class references.

// public SomeItemClass = class of SomeItem;

 

Message based dynamic methods.

// public message(1) void DoSomething(ref MessageArgs messageArgs) { }

instance.

Type aliasing has been in C# since the beginning.

using StringList = System.Collections.List<System.String>;

the only problem with the syntax is that unless a type is specified with a keyword (string/int/etc) you must use the full type name, which gets tedious after a while. I'd prefer it if it respected existing namespace imports to resolve type names.

sysrpl said:

Virtual constructors.

// public virtual SampleObject(string name)  {  }

 

Virtual static methods.

// public static virtual DoSomething() { }

 

Virtual static constructors.

 // public static virtual SampleObject(string name)  {  }

 

Enumeration set operations.

// textBox.Anchors += { AnchorStyles.Right, AnchorStyles.Bottom };

 

Implementation through delegation.

// public class SomeItems : IList<SomeItem> { private List<SomeItem> items; private implements IList<SomeItem> GetList() { return items; }  }

 

Static method extensions.

// public static void DoSomething(this SomeType, string message);

 

Property extensions.

// public string FunnyName { this SomeType; get; set; }

 

Static property extensions.

// public static string FunnyName { this SomeType; get; set; }

 

Type aliases.

// public typedef SomeItemList = List<SomeItem>;

 

Expando properties and methods.

// instance.SomeNewProperty = 12; instance.SomeNewMethod = (string message) => MessageBox.Show(message);

 

Class references.

// public SomeItemClass = class of SomeItem;

 

Message based dynamic methods.

// public message(1) void DoSomething(ref MessageArgs messageArgs) { }

instance.

@sysrpl

"Expando properties and methods.

// instance.SomeNewProperty = 12; instance.SomeNewMethod = (string message) => MessageBox.Show(message);"

I don't know... Perhaps only in a dynamic context?

dynamic instance = GetInstance();
instance.SomeNewProperty = 12;
instance.SomeNewMethod = (string message) => MessageBox.Show(message);

Just like vb.net has XML Literals.

#Language="vb.net"
Public Module Module1

 Sub Main()
Dim n1 As Double=2
Dim n2 As Double=3
Dim result = Addition(n1,n2)
 Console.WriteLine(result)
 Console.ReadKey()
 End Sub
#EndLanguage
 
#Language="c#"
 public  double Addition(double x, double y) {
 return x + y;
}
#EndLanguage

The c# is probably wrong (not my best) but you get the gist.

Developers coding in prefered language.

I don't think it be that hard to implement, all the required mechnisms are already built; the compilers. It may need a new linker.

AdamSpeight2008 said:

The ability to blend the different .net languages in a the same sourcecode, through the use of a new # tag.

Just like vb.net has XML Literals.

 

#Language="vb.net"
Public Module Module1

 Sub Main()
Dim n1 As Double=2
Dim n2 As Double=3
Dim result = Addition(n1,n2)
 Console.WriteLine(result)
 Console.ReadKey()
 End Sub
#EndLanguage
 
#Language="c#"
 public  double Addition(double x, double y) {
 return x + y;
}
#EndLanguage

The c# is probably wrong (not my best) but you get the gist.

Developers coding in prefered language.

 

I don't think it be that hard to implement, all the required mechnisms are already built; the compilers. It may need a new linker.

 

Blending languages would be nice, although I'd be happy with files being in one language but projects being in multiple. So if I find a neat class on the web that's in C# but I want to use it in my VB project, and I don't want two DLLs, I don't need to translate the C# to VB (and inevitably introduce errors).

spivonious said:

AdamSpeight2008 said:

*snip*

Blending languages would be nice, although I'd be happy with files being in one language but projects being in multiple. So if I find a neat class on the web that's in C# but I want to use it in my VB project, and I don't want two DLLs, I don't need to translate the C# to VB (and inevitably introduce errors).

Just integrate ILMerge into your build process.

But is translating from VB to C# and back really that hard? Given most samples I see online (like on CodeProject) are in C# I think it'd be better to use C# anyway. The only VB samples I see are for trivial things because the people who consume them are beginners who are still finding their feet.

W3bbo said:

spivonious said:

*snip*

Just integrate ILMerge into your build process.

 

But is translating from VB to C# and back really that hard? Given most samples I see online (like on CodeProject) are in C# I think it'd be better to use C# anyway. The only VB samples I see are for trivial things because the people who consume them are beginners who are still finding their feet.

It would allow the coder to be more productive, since you eliminate the translation process.

AdamSpeight2008 said:

W3bbo said:

*snip*

It would allow the coder to be more productive, since you eliminate the translation process.

I disagree there. When I translate code I'm forced to read it and see how it works, which is a good thing: it means I understand what my code is doing rather than doing "copy and paste programming".