C# 8.0 release date questions

[Korporal]

Is it true that C# 8 will be formally released when VS 2019 is formally released on Tuesday? Or is the release of the compiler decoupled from the release of VS 2019?

[YairHalberstadt]

They are decoupled. However you can continue using the preview version.

[Korporal]

@YairHalberstadt - OK thanks, so when will C# 8.0 be released (if a dates has been set)?

[Korporal]

By the way the reason I ask is that we'd like to know when this bug fix will become available (other than as a beta).

dotnet/roslyn#31439

[AdrianJSClark]

From the "Announcing .NET Core 3 Preview 3" blog post:

We plan to ship .NET Core 3.0 in the second half of 2019. We will announce the ship date at the Build 2019 conference.

So you'll find out during Build (May 6-8) what the ship date will be.

[Korporal]

Hmm - so its taking possibly > 6 months to fix a rather fundamental compiler bug? Wow. Also it seems that there is still a bug in this area (the compiler crash has gone though) and compiling a simple test in the latest RC VS 2019 with C# 8 generates (what seems to be) an incorrect error.

[Korporal]

From the "Announcing .NET Core 3 Preview 3" blog post:

We plan to ship .NET Core 3.0 in the second half of 2019. We will announce the ship date at the Build 2019 conference.

So you'll find out during Build (May 6-8) what the ship date will be.

@AdrianJSClark - Hi, I read that article and I don't see anything that states the release of C# 8.0 hinges on the release of .Net Core 3.

Ahh my apologies, this is stated here:

https://devblogs.microsoft.com/dotnet/building-c-8-0/

[HaloFour]

@Korporal

I could be wrong but I would presume that VS2019 would ship with a new version of the compiler regardless of whether C# 8.0 is released. IIRC that compiler will support C# 8.0 features in experimental mode. Question might be whether or not that version of the compiler contains the bugfix you referenced?

[AdrianJSClark]

Even the language in that "Building C# 8.0" post you have there allows the possibility of C# 8.0 being shipped separately from .NET Core 3.0, however I made my comment based on not having seen anything that suggests this was likely to happen. One of the team could jump in here to correct me though.

[Korporal]

@HaloFour - Hi, yes it seems that VS 2019 will provide that fix. Currently in VS 2019 v 16.0.0 Preview 4.4 (I guess this is the final RC build) the fix is there (in that the stack overflow has gone away which was crashing VS 2017) in C# 7.3 and C# 8.0 (beta).

However the fix seems to be to cleanly fail the compile with CS 8377.

I had expected this to compile though:

namespace ConsoleApp3
{
    class Program
    {
        static void Main(string[] args)
        {
        }
    }

    public struct X<T> where T : unmanaged
    {

    }

    public struct Z
    {
        private X<Z> field;
    }
}

Changing unmanaged to struct compiles fine. I don't understand why it doesn't compile when we use unmanaged - am I missing something dumb here?

Even more confusing is this:

That code crashes the IDE in VS 2017 when I use C# 7.3
That code does not crash the IDE in VS 2019 when I use either C# 7.3 or C# 8.0 (beta).

Clearly the compiler for C# 7.3 in VS 2017 is different from the compiler for C# 7.3 in VS 2019.

Since C# 7.3 is fully released this means that fix was made to the v 7.3 of the compiler (language?) and will be fully available when VS 2019 is released next week (if we use C# 7.3). But it is not fixed when we use VS 2017 even if we select the same C# version - 7.3.

All rather confusing!

[Korporal]

Just to be clear I had expected the fix to accept that code and compile fine, it seems the fix is actually to prevent the stack overflow and instead issue a diagnostic:

The type 'Z' must be a non-nullable value type, along with all fields at any level of nesting, in order to use it as parameter 'T' in the generic type or method 'X<T>'

BUT is that diagnostic correct? why can't the code compile?

[Korporal]

This slight variant does compile:

namespace ConsoleApp3
{
    class Program
    {
        static void Main(string[] args)
        {
        }
    }

    public struct X<T> where T : unmanaged
    {

    }

    public struct Z
    {
        //private X<Z> field;
    }

    public struct W
    {
        private X<Z> field;
    }
}

[HaloFour]

This might be a better question for the Roslyn repository, by the way.

[CyrusNajmabadi]

BUT is that diagnostic correct? why can't the code compile?

That is likely a better question for the Roslyn repository.

[CyrusNajmabadi]

Clearly the compiler for C# 7.3 in VS 2017 is different from the compiler for C# 7.3 in VS 2019.

Yes. This is how it always works. You are always getting the latest compiler when you get a new VS. However, that compiler can be passed flags about what language features are allowed or not. So, when you specify 7.3 compilation for hte latest compiler, it simply will disallow any features that came after 7.3.

There is only ever one binary of the c# compiler that is shipped. But that one binary knows how what is allowed or not for every version of the language.

[CyrusNajmabadi]

But it is not fixed when we use VS 2017 even if we select the same C# version - 7.3.

Correct, things are rarely backported to previously shipped compilers unless absolutely critical. As mentioned in your original bug report:

Every bug is triaged and prioritized based on impact (how common is it, how bad is the experience), risk of change, and some other factors (regression, compatibility, etc). The bar for fixing issues in VS 2017 is very high at this point, and this bug does not meet that bar.

That hasn't changed. Backporting a fix to 2017 would only happen for the most critical of issues affecting many customers. Clearly, this bug is not in that category.

[spydacarnage]

The last I've heard is that there is an announcement expected soon, but the actual release date is likely to be around September. Of course, that was on [insert random IT news site], so take with as large a pinch of salt as you can find...

…

On Sun, 31 Mar 2019, 14:52 Hugh Gleaves, ***@***.***> wrote: Is it true that C# 8 will be formally released when VS 2019 is formally released on Tuesday? Or is the release of the compiler decoupled from the release of VS 2019? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2380>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ANBBwROv8vkJO_tyeTnBLBddRZutfP35ks5vcL2pgaJpZM4cUUnj> .

[Korporal]

@CyrusNajmabadi - So am I correct that there are two distinct C# compilers present on a machine that has two distinct versions of Visual Studio installed?

[YairHalberstadt]

Yep

[Korporal]

This might be a better question for the Roslyn repository, by the way.

@HaloFour @CyrusNajmabadi - Thanks, I have raised this in the original (now closed) issue in the roslyn repository.

However as C# gurus are you not able to tell if the fragment should compile or should report an error? This is a language question surely, not so much a question about an implementation of that language?

[PathogenDavid]

The CLR does not like structs with fields that use a generic type with themselves as a parameter. If you remove your generic constraint, you'll get a TypeLoadException for Z. So even if your code compiled, it isn't going to work.

Someone who is more familiar with CLR guts could tell you for sure, but I suspect it's because the CLR needs to know the size of X<Z> to compute the layout of Z, but it can't do that because Z is still being loaded when creating X<Z>. The compiler is probably failing for similar reasons, but the error should probably be different. (Something similar to CS0523.)

What exactly are you trying to accomplish?

[Korporal]

The CLR does not like structs with fields that use a generic type with themselves as a parameter. If you remove your generic constraint, you'll get a TypeLoadException for Z. So even if your code compiled, it isn't going to work.

Someone who is more familiar with CLR guts could tell you for sure, but I suspect it's because the CLR needs to know the size of X<Z> to compute the layout of Z, but it can't do that because Z is still being loaded when creating X<Z>. The compiler is probably failing for similar reasons, but the error should probably be different. (Something similar to CS0523.)

What exactly are you trying to accomplish?

@PathogenDavid - Now that's a very good question! Unfortunately I can't recall 100%. The bug (Visual Studio dying) arose during some refactoring of experimental code that does some powerful stuff with unmanaged memory (memory within the address space of a process that is situated outside of the AppDomain). The recent C# support for stuff like improved ref and unmanaged constraint etc, suggested a way to simplify and improve some core code we have.

During the course of this experimentation this crash arose and because it kept causing the IDE to hang then die and then hang and die again when restarted (because when VS restarts and opens a previously open solution it opens the files that were open - including the one I had edited) - the mere presence of the code fragment was killing VS.

If I recall in order to be able to actually open the solution I had to edit the source file with Notepad and remove the changes (or I may have done a Git discard) and so because of this very unusual situation I can't clearly recall what I was doing at the time.

I did have enough info to explain it in the roslyn bug report I submitted and now its been four months and I've not looked at this code for that long.

At the back of my mind I was expecting the fix to have a) stopped the VS crash and b) actually compile what I considered to be legal C# code. So once fixed I planned to review the solution again and probably recall what I was trying to do, but if this is not legal C# then it's a waste for me to do that!

[PathogenDavid]

Yeah, definitely sounds like a frustrating situation to find yourself in. If you happen to remember, I'd be curious to know.

For future reference, you can pretty easily consume beta releases of the compiler in older versions of Visual Studio by consuming pre-release versions of the Microsoft.CodeAnalaysis.CSharp NuGet package. (Nightly builds are on MyGet.) That way you don't have to sit around waiting for a Visual Studio update.

Clearly the compiler for C# 7.3 in VS 2017 is different from the compiler for C# 7.3 in VS 2019.

If you ever want to check for sure what version of Roslyn is being used to build your code, add #error version somewhere in your code. (You can also turn up the MSBuild verbosity and the command line including the path to csc.exe will be printed.)

[CyrusNajmabadi]

@CyrusNajmabadi - So am I correct that there are two distinct C# compilers present on a machine that has two distinct versions of Visual Studio installed?

Yes. That is correct.

However as C# gurus are you not able to tell if the fragment should compile or should report an error? This is a language question surely, not so much a question about an implementation of that language?

I can look into it on monday. However, based on the code I can def see why it might be problematic. Though being able to quote chapter and verse on what's wrong might take some effort. Given that these are structs, and you're self-referencing types, i def think you're opening yourself up to a world of hurt.

[Korporal]

@CyrusNajmabadi - Thanks for looking at this.

Note that this compiles fine by the way:

namespace ConsoleApp3
{
    class Program
    {
        static void Main(string[] args)
        {
        }
    }

    public struct X<T> where T : struct // T : unmanaged causes compile error.
    {

    }

    public struct Z
    {
        private X<Z> field;
    }
}

[CyrusNajmabadi]

Possibly because T isn't used in X. Which means it isn't used for the size computation. Is this realistic? Would you really not end up using T in the body of X ?

The problem i'm having here is that this example is too abstract to understand why you'd want it or what value it would have to support making it work. Could you potentially ground it in something more real-world?

[HaloFour]

Whether or not it should compile, the crash is obviously wrong and the compiler diagnostic when it doesn't crash isn't clear and doesn't seem to be related. I'm not sure I get why struct would work but unmanaged wouldn't?

[Korporal]

Possibly because T isn't used in X. Which means it isn't used for the size computation. Is this realistic? Would you really not end up using T in the body of X ?

The problem i'm having here is that this example is too abstract to understand why you'd want it or what value it would have to support making it work. Could you potentially ground it in something more real-world?

@CyrusNajmabadi - That's a totally fair question and I apologize for not providing this, I will try to reeaxmine the original code I was using to see if I can recall what the attempted refactor was. The refactoring itself was a simplification of existing code, being able to use "ref" as we now can made the code much slicker, as I was refactoring it an idea came up that led to this bug being exposed.

I'll try to get back with more soon...

[CyrusNajmabadi]

Thanks!

[Daniel15]

So was the C# 8.0 release date announced at Build?

[yaakov-h]

IIRC it was announced as "same time as .NET Core 3.0", which is slated for September some time.

[ashmind]

Is C# 8 officially released? It seems to be mentioned in .NET Core 3 release, but there is no clear announcement similar to https://devblogs.microsoft.com/dotnet/announcing-f-4-7/ and https://docs.microsoft.com/en-us/dotnet/csharp/whats-new/csharp-8 still shows "Preview 5".

[jmarolf]

C# 8 is officially released with .NET Core 3.0 and VS 2019.3 being released

[Daniel15]

@ashmind - It's mentioned in this post: https://devblogs.microsoft.com/dotnet/announcing-net-core-3-0/

[333fred]

As C# 8 is out, I'm closing this issue.