C# 6.0

[Emily]

Hey,

I was wondering what you're all thinking of the new C# 6.0 in the Visual Studio 2015 Preview.

You must be registered to see links

I think it has some nice things in it. Have just downloaded it and going to try it out real quick!

 

[The General]

I still miss static local variables though.

I like it how it is possible to use a static class as a namespace Pretty neat and makes it more readable however you still have to know the method is within that certain class. Imagine if you have 100 static classes included. How'd you know without using the IDE where it comes from. Double feelings on it.

Auto property initialiser is cool :

 

[Emily]

I still miss static local variables though.

I like it how it is possible to use a static class as a namespace Pretty neat and makes it more readable however you still have to know the method is within that certain class. Imagine if you have 100 static classes included. How'd you know without using the IDE where it comes from. Double feelings on it.

Auto property initialiser is cool :

True, also, the new way of string formatting is pretty neat too, one of the things I like the most.

 

[Jangan]

Pssht... took microsoft long enough to upgrade the crappy Dictionary system. >.>

 

[Taiga]

I was like, I want now. (Yes, like the broken English) when I saw their announcement

 

[Emily]

Pssht... took microsoft long enough to upgrade the crappy Dictionary system. >.>

Well, that's a true thing lol. At least some things are going the right way now.

 

[Yekun]

I'm excited about the string interpolation. It's Good feature.

 

[jademaster]

sir codedragon may i have a work with you pls? i would like to make some inquiries.. dont worry im not going to ask you to give me something or ask about tutorials.. i cant pm you so where could i contact you?

 

[שเ๒єtгเ๒є]

you still have to know the method is within that certain class. Imagine if you have 100 static classes included. How'd you know without using the IDE where it comes from. Double feelings on it.

• Exactly, using static namespaces is not a good approach IMHO, because it makes it harder to understand where the call is to. Giving the example to use Toint32() instead of Convert.ToInt32() results in being confused ToInt32 is from Convert or from the own class in the first moment. Totally dislike to this.
  
• Also the property initializer is useless. For such feature you should use a field instead. If you want to capsule it, setting the value on the initial state would only make sense when not writing any behavior in the setter accessor. Once you write a behavior in the setter, you need an extra field behind it to get or set values from/to it. And once this happens, you can simply initialize the value to the back-field initialization.
  For the specific property case where you can initialize a value to the property while it has only a getter accessor, for this there is the readonly keyword for fields.
  
• The new way of the dictionary initializer is nice and reminds me on JSON, however not needed, too. But well, it's okay.
  
• The nameof keyword is very a golden piece in this update, because this is something that was missed and resulted in bad thrown exceptions. Programmers had to pass the real name of the variable to help the user to track down to the exception. So they mostly did not, because of laziness.
  
• Exception filters, screw them, because you can make such statements in the catch block, too.
  
• The new await features are necessary, I totally missed this is not implemented so far.
  
• 
  The null-conditional operator is really what this language needs. Many times I compare properties of nested objects against null, so this makes it so much easy. I just wonder what it returns when the object is null. In the given example what do I get when emp is null and I Console.Write(emp?.Name) without the false condition that can be used with ??
  Hm will it might return the default() of the type of Name?
  Also in a condition, will using emp? or emp?.Name return false when emp is null?
  If anybody knows, please share it
  
• The expression-bodied methods are fine, they can maybe make the code shorter. In most circumstances I would rather build a getter property for this. Without this feature you can even write it in all line, whatever.
  
• The new format string feature ..., what should I say, it's going towards inline coding styles such as at PHP, I hope they won't mess it up more. When it stays like this, it gonna be very good, though.

 

[Emily]

• Exactly, using static namespaces is not a good approach IMHO, because it makes it harder to understand where the call is to. Giving the example to use Toint32() instead of Convert.ToInt32() results in being confused ToInt32 is from Convert or from the own class in the first moment. Totally dislike to this.
  
• Also the property initializer is useless. For such feature you should use a field instead. If you want to capsule it, setting the value on the initial state would only make sense when not writing any behavior in the setter accessor. Once you write a behavior in the setter, you need an extra field behind it to get or set values from/to it. And once this happens, you can simply initialize the value to the back-field initialization.
  For the specific property case where you can initialize a value to the property while it has only a getter accessor, for this there is the readonly keyword for fields.
  
• The new way of the dictionary initializer is nice and reminds me on JSON, however not needed, too. But well, it's okay.
  
• The nameof keyword is very a golden piece in this update, because this is something that was missed and resulted in bad thrown exceptions. Programmers had to pass the real name of the variable to help the user to track down to the exception. So they mostly did not, because of laziness.
  
• Exception filters, screw them, because you can make such statements in the catch block, too.
  
• The new await features are necessary, I totally missed this is not implemented so far.
  
• 
  The null-conditional operator is really what this language needs. Many times I compare properties of nested objects against null, so this makes it so much easy. I just wonder what it returns when the object is null. In the given example what do I get when emp is null and I Console.Write(emp?.Name) without the false condition that can be used with ??
  Hm will it might return the default() of the type of Name?
  Also in a condition, will using emp? or emp?.Name return false when emp is null?
  If anybody knows, please share it
  
• The expression-bodied methods are fine, they can maybe make the code shorter. In most circumstances I would rather build a getter property for this. Without this feature you can even write it in all line, whatever.
  
• The new format string feature ..., what should I say, it's going towards inline coding styles such as at PHP, I hope they won't mess it up more. When it stays like this, it gonna be very good, though.

Knowing Microsoft, it'll get more updated eventually.

 

[The General]

• Exactly, using static namespaces is not a good approach IMHO, because it makes it harder to understand where the call is to. Giving the example to use Toint32() instead of Convert.ToInt32() results in being confused ToInt32 is from Convert or from the own class in the first moment. Totally dislike to this.

• 
  
  What is the behaviour if you use two static classes as namespace which both have the method ToInt32. Does it still requires you to write the full class name (thus making it useless to use it as a namespace). If it does check on that does it see a difference between bool ToInt32 and void ToInt32 (May not be logical but just for the sake of this question).
  
  If someone has sed 6.0 already, let me know. Just curious.

 

[Caustik]

static namespaces don't seem like a massive feature, can't see a use for them

 

[שเ๒єtгเ๒є]

What is the behaviour if you use two static classes as namespace which both have the method ToInt32. Does it still requires you to write the full class name (thus making it useless to use it as a namespace). If it does check on that does it see a difference between bool ToInt32 and void ToInt32 (May not be logical but just for the sake of this question).

If someone has sed 6.0 already, let me know. Just curious.

It won't see that. In C# the signature check usually does not include the return type, i.e. overloading does not work when having to different return types and same parameter signature.
And when referencing two different namespaces that contain the same class it will claim for duplication, so why it should be different on methods?

I hope nobody will program like that at all, I even dislike to read code where people simply are to lazy to use the this. prefix when accessing own members, making me think "is this a local scope or class scope one I'm dealing with?", until I hover it.

 

[The General]

It won't see that. In C# the signature check usually does not include the return type, i.e. overloading does not work when having to different return types and same parameter signature.
And when referencing two different namespaces that contain the same class it will claim for duplication, so why it should be different on methods?

I hope nobody will program like that at all, I even dislike to read code where people simply are to lazy to use the this. prefix when accessing own members, making me think "is this a local scope or class scope one I'm dealing with?", until I hover it.

And lets don't start about the people using leading underscores for member attributes :

Oh and typedef would be cool to have.

 

[xStr0nGx]

I like it

Good job Microsoft!