New Language Features in C# 6

Topics: C# Language Design
Coordinator
Nov 12, 2014 at 3:19 PM
Hi all,

Today we release the Visual Studio 2015 Preview. I've updated the language feature list for C# and Visual Basic here, and you can read more details about the C# language features here.

As you'll know from threads here on CodePlex, a few of the features are still in flux: String interpolation and nameof both have pending design changes in C#, and haven't been implemented yet in VB. Other than those, though, there are no further planned changes to the language feature sets as they now stand.

Now stop reading, and go download the Preview!
Nov 12, 2014 at 7:04 PM
Edited Nov 12, 2014 at 9:45 PM
why are features like primary constructors, etc. not included? that's really not cool.

I tested different features like primary ctors and stuff like "dic.TryGetValue(0, out int value);" but the best features arent working

// Edit
I saw they where cutted off....
That's very sad since both of them worked fine and made some code much more nicer and readable.
That really sucks!!!

Code like:
namespace Framework.Packets.Server.Character
{
    public class CharacterLoginFailed() : ServerPacket(GlobalServerMessage.CharacterLoginFailed)
    {
        public CharLoginCode Code { get; set; }

        public override void Write()
        {
            Packet.Write((byte)Code);
        }
    }
}
looks really much cleaner than:
namespace Framework.Packets.Server.Character
{
    public class CharacterLoginFailed : ServerPacket
    {
        public CharLoginCode Code { get; set; }

        public CharacterLoginFailed() : base(GlobalServerMessage.CharacterLoginFailed) { }

        public override void Write()
        {
            Packet.Write((byte)Code);
        }
    }
}
or
[AttributeUsage(AttributeTargets.Method)]
public sealed class MessageAttribute : Attribute
{
    public ClientMessage Message { get; }

    public MessageAttribute(ClientMessage message)
    {
        Message = message;
    }
}

// primary ctor..
[AttributeUsage(AttributeTargets.Method)]
public sealed class MessageAttribute(ClientMessage message) : Attribute
{
    public ClientMessage Message { get; } = message;
}
and it really worked fine without any issues :/
Nov 12, 2014 at 10:02 PM
Nov 12, 2014 at 10:36 PM
there is still no good reason in that posts why it is cut of...
Developer
Nov 12, 2014 at 11:24 PM
@king48488
There were several reasons, here are a few (TLDR: We ran out of time and didn't feel confident enough about the feature)
  • As the syntax for primary constructors evolved it eventually morphed into a complete alternate constructor syntax. This is not necessarily a negative but it's not really desirable to introduce two ways of doing things if one isn't significantly better than the other in certain situations. In our use of the feature internally it rarely saved much code. Even in the example above you only save a single line of typing. Once you add in argument validation you rarely save any typing, it just looks different.
  • The decision to not support primary constructors in structs and to not introduce records types also meant that the feature would not be useful in the scenarios we originally intended: declaring immutable data types. We plan to re-evaluate adding record types in the next release and didn't want to hamper that design with whatever compromises were made for primary constructors
  • Refactorings, codefixes, etc. the final bit of polish that we always want to do in the IDE to make a feature feel great, was coming together slower than we would have liked.
All these contributed to the hard decision to cut primary constructors. This doesn't mean we don't like the idea. We'll probably revisit it. Just that we never want to ship a feature were not 100% sure will be great.
Nov 13, 2014 at 8:45 AM
What about '?.' in expression trees?

Any chance this will be included? There's a tiny pull request asking for attention :(

Pull request https://roslyn.codeplex.com/SourceControl/network/forks/Olmo/NullPropagationExpresions/contribution/7667 is just a small change on top of KevinRansom/PreviewCloneAndGo in branch releases/Dev14Ctp3

Mini spec: https://roslyn.codeplex.com/discussions/571077
Nov 13, 2014 at 1:38 PM
What about field-targeted attributes on auto-properties? This was on the short-list earlier as something that was going to be fixed and mentioned a couple of times on the VB.NET forums. It would bring auto-properties on par with the functionality of events which has supported this since C# 1.0.
public class Foo {
    [field: NonSerialized] // already supported
    public event EventHandler Bar;

    [field: NonSerialized] // not supported in C# 5.0
    public string Baz { get; set; }
}
Developer
Nov 13, 2014 at 5:20 PM
Halo_Four wrote:
What about field-targeted attributes on auto-properties? This was on the short-list earlier as something that was going to be fixed and mentioned a couple of times on the VB.NET forums. It would bring auto-properties on par with the functionality of events which has supported this since C# 1.0.
public class Foo {
    [field: NonSerialized] // already supported
    public event EventHandler Bar;

    [field: NonSerialized] // not supported in C# 5.0
    public string Baz { get; set; }
}
They didn't get done in time.
Nov 14, 2014 at 5:33 PM
madst wrote:
Hi all,

Today we release the Visual Studio 2015 Preview. I've updated the language feature list for C# and Visual Basic here, and you can read more details about the C# language features here.

As you'll know from threads here on CodePlex, a few of the features are still in flux: String interpolation and nameof both have pending design changes in C#, and haven't been implemented yet in VB. Other than those, though, there are no further planned changes to the language feature sets as they now stand.

Now stop reading, and go download the Preview!
Is String Interpolation in this preview at all? I can't seem to get any flavor of it to work.
Coordinator
Nov 14, 2014 at 5:48 PM
@MgSam: String interpolation is in the preview, though for C# only (VB comes later) and with an earlier syntax:
var s = "\{person.Name} is \{person.Age:d3} years old.";
Try it out!
Nov 14, 2014 at 7:36 PM
madst wrote:
@MgSam: String interpolation is in the preview, though for C# only (VB comes later) and with an earlier syntax:
var s = "\{person.Name} is \{person.Age:d3} years old.";
Try it out!
Where is all of that at, by the way? I saw the proposal for switching back to $-prefixed and eliminating escape sequences but the verbiage of that post made it sound like it had not yet been discussed during the team design meetings.

I'm still a fan of having both syntaxes, the non-prefixed version with escape-sequence holes and the $-prefixed syntax which behaves identically to this second proposal as a form of interpolated verbatim string.
var s1 = "\{person.Name} is \{person.Age:d3} years old.";
var s2 = $"{person.Name} is {person.Age:d3} years old.";
Nov 17, 2014 at 2:06 PM
Halo_Four wrote:
madst wrote:
@MgSam: String interpolation is in the preview, though for C# only (VB comes later) and with an earlier syntax:
var s = "\{person.Name} is \{person.Age:d3} years old.";
Try it out!
Where is all of that at, by the way? I saw the proposal for switching back to **Halo_Four wrote:**
-prefixed and eliminating escape sequences but the verbiage of that post made it sound like it had not yet been discussed during the team design meetings.

I'm still a fan of having both syntaxes, the non-prefixed version with escape-sequence holes and the
**Halo_Four wrote:**
-prefixed syntax which behaves identically to this second proposal as a form of interpolated verbatim string.
var s1 = "\{person.Name} is \{person.Age:d3} years old.";
var s2 = $"{person.Name} is {person.Age:d3} years old.";
On @Madst message there's a link to a documnet (https://www.codeplex.com/Download?ProjectName=roslyn&DownloadId=930852) withe the implemented features.

On the chapter related to string interpollation (§5) you can read
Nov 17, 2014 at 2:19 PM
PauloMorgado wrote:
On @Madst message there's a link to a documnet (https://www.codeplex.com/Download?ProjectName=roslyn&DownloadId=930852) withe the implemented features.

On the chapter related to string interpollation (§5) you can read
Yes, I did read that. I was just hoping for a little more insight as to how that decision was reached, and to take the opportunity to again plug my preference of supporting both syntaxes, especially since the $ prefix now behaves more like a verbatim string.
Nov 17, 2014 at 2:28 PM
Halo_Four wrote:
PauloMorgado wrote:
On @Madst message there's a link to a documnet (https://www.codeplex.com/Download?ProjectName=roslyn&DownloadId=930852) withe the implemented features.

On the chapter related to string interpollation (§5) you can read
Yes, I did read that. I was just hoping for a little more insight as to how that decision was reached, and to take the opportunity to again plug my preference of supporting both syntaxes, especially since the `**Halo_Four wrote:**
prefix now behaves more like a verbatim string.
It's sctared amongs several discussions. You probable blinked twice and missed it.

It doesn't behave like verbatim strings. You can apply the $ modifier to literal and verbatim strings and the interpolation will be applied to pattern string.
Nov 17, 2014 at 3:05 PM
PauloMorgado wrote:
Halo_Four wrote:
PauloMorgado wrote:
On @Madst message there's a link to a documnet (https://www.codeplex.com/Download?ProjectName=roslyn&DownloadId=930852) withe the implemented features.

On the chapter related to string interpollation (§5) you can read
Yes, I did read that. I was just hoping for a little more insight as to how that decision was reached, and to take the opportunity to again plug my preference of supporting both syntaxes, especially since the `**Halo_Four wrote:**
prefix now behaves more like a verbatim string.
It's sctared amongs several discussions. You probable blinked twice and missed it.

It doesn't behave like verbatim strings. You can apply the $ modifier to literal and verbatim strings and the interpolation will be applied to pattern string.
Where was that decision? The PDF doesn't discuss it and the thread on the subject only mentioned that it would be discussed as a possibility but I see no additional comments or decisions.

According to the design decisions at the top of that thread:

Changes since v1

  1. Interpolated strings are now more like verbatim strings than ordinary strings:
    • They may occupy multiple lines and contain newlines
    • The only characters that require escaping are ", {, and } which are escaped by doubling
    • The number of fill-ins in the format string is guaranteed to be the same as the number of interpolations
  2. System.Runtime.CompilerServices.FormattedString changes:
    • FormattedString is now a struct type.
    • There is a conversion from an interpolated string expression to FormattedString
    • Added properties Format and Args to access the compiler-generated composite format string and fill-in values
My comments are based on these specific changes and I reference that specific verbiage that interpolated strings are now more like verbatim strings. As such, combining the two prefixes wouldn't even make sense.

If you have newer information on the subject that contradicts this then I'd love to read it.
Nov 17, 2014 at 4:28 PM
Halo_Four wrote:
PauloMorgado wrote:
Halo_Four wrote:
PauloMorgado wrote:
On @Madst message there's a link to a documnet (https://www.codeplex.com/Download?ProjectName=roslyn&DownloadId=930852) withe the implemented features.

On the chapter related to string interpollation (§5) you can read
Yes, I did read that. I was just hoping for a little more insight as to how that decision was reached, and to take the opportunity to again plug my preference of supporting both syntaxes, especially since the `**Halo_Four wrote:**
prefix now behaves more like a verbatim string.
It's sctared amongs several discussions. You probable blinked twice and missed it.

It doesn't behave like verbatim strings. You can apply the `**Halo_Four wrote:**
modifier to literal and verbatim strings and the interpolation will be applied to pattern string.
Where was that decision? The PDF doesn't discuss it and the thread on the subject only mentioned that it would be discussed as a possibility but I see no additional comments or decisions.

According to the design decisions at the top of that thread:

Changes since v1

  1. Interpolated strings are now more like verbatim strings than ordinary strings:
    • They may occupy multiple lines and contain newlines
    • The only characters that require escaping are ", {, and } which are escaped by doubling
    • The number of fill-ins in the format string is guaranteed to be the same as the number of interpolations
  2. System.Runtime.CompilerServices.FormattedString changes:
    • FormattedString is now a struct type.
    • There is a conversion from an interpolated string expression to FormattedString
    • Added properties Format and Args to access the compiler-generated composite format string and fill-in values
My comments are based on these specific changes and I reference that specific verbiage that interpolated strings are now more like verbatim strings. As such, combining the two prefixes wouldn't even make sense.

If you have newer information on the subject that contradicts this then I'd love to read it.
Looks like I'm the one who blinked twice.

This has gone back and forth so many times that I'm now lost.
Nov 17, 2014 at 5:27 PM
PauloMorgado wrote:
Looks like I'm the one who blinked twice.

This has gone back and forth so many times that I'm now lost.
I hear that. I think that's why I like having both syntaxes, it satisfies the requests from both major camps. The reason I don't like the current $-prefixed syntax is that it tosses all escape sequences which I think would still be useful.
Nov 18, 2014 at 4:34 AM
It's too bad not to include Declaration Expressions which was presented in Build 2014. It is one of the nicest and most useful features which should be added into C# 6. For example,
int i;
if (Int32.TryParse("10", out i))
{
    Console.WriteLine(i);
}
Only for the out parameter, we need to declare a variable in a separate line. I really can't understand why you didn't include Declaration Expressions so we can omit "i" here.
Developer
Nov 18, 2014 at 7:30 PM
Edited Nov 19, 2014 at 4:22 PM
jaliyaudagedara wrote:
It's too bad not to include Declaration Expressions which was presented in Build 2014. It is one of the nicest and most useful features which should be added into C# 6. For example,
int i;
if (Int32.TryParse("10", out i))
{
    Console.WriteLine(i);
}
Only for the out parameter, we need to declare a variable in a separate line. I really can't understand why you didn't include Declaration Expressions so we can omit "i" here.
We didn't include it because the (language) design issues turned out to be more complicated than we anticipated, some of which might impact our ability to extend the language further, for example in adding pattern matching. Because of the open issues, we had an unknown amount of additional work to do (depending on how the open issues are resolved). Given the short amount of time we have to make any changes, we would rather cut the feature than make compromises in the design and in our ability to extend the language in the future.