Roslyn: Cannot change compiler language version

[miloush]

Version Used: 16.3 Preview 1.0

Steps to Reproduce:
Project properties > Build > Advanced...

Actual Behavior:

Ironically the link does not answer the question. Why can I no longer specify the language version? There has always been new language features that required various classes but they could have been provided in the project if needed.

How does this work with flavoured projects?

[svick]

The PR that disabled it is https://github.com/dotnet/project-system/pull/4923, though it doesn't really explain why. It does say that the link is only temporary and should point to a better explanation later.

I suspect it's part of the new policy, where new language versions are only supported by new framework versions, see e.g. the Platform dependencies section of Building C# 8.0. I understood that the new policy meant "we won't provide NuGet packages for older frameworks", but now it seems it also means "we will actively fight you if you try to use any new language feature on older frameworks, even those that don't require framework support". I'm not sure I like that, especially since the language version selector is already in the "Advanced" section.

[sharwell]

/cc @cartermp for answering this question

[cartermp]

This is by design. As the linked article states, the language version is chosen by target framework. You can override the choice by manually setting LangVersion in your project file, though this comes with the caveat that not everything is guaranteed to work.

[miloush]

This has never been the case before, why has this changed? The setting is already hidden in an advanced dialog box, and has been working previously the same way it needs to work now.

[miloush]

Worse, the dialog does not reflect the actual LangVersion set in the project file, so the "Automatically selected based on framework version" is simply a lie.

You get, for example, a CS8107 saying _a feature X is not available in C# 7.0. Please use language version 7.1 or greater_. So you go the project properties and it says selected automatically and you cannot change it. If you are lucky enough you realize what's going on, you need to unload the project, edit the project file manually (after you figure out what are the project properties and values you need to write) and reload it again.

Which users will benefit from this design change (so much that it was worth the development, testing and localization investment)?

[gafter]

@cartermp That does not explain why I cannot use the form to revert to an older language version. Can you please explain why that ability was removed from the form?

[cartermp]

@gafter Oh, mostly just the nasty combination of late decisions and not enough time to really do something thoroughly. At the time, it needed to get in, and there was no API to understand the highest-supported language version for a given TFM. So there wasn't a way to restrict what is selectable without hardcoding everything. We might revisit that, but we're also considering removing the dropdown altogether if the data points we inserted for 16.3 show that barely anyone touches it.

[miloush]

@cartermp There is no need to restrict anything - as you said, users can choose the language version using manually editing the project file, so I don't see why API should be more restricted than that.

What exactly are the data points meant to show? You have disabled the functionality so there is no point for users to open the dialog for this purpose anymore.

[PathogenDavid]

I don't really understand the need for this restriction when the compiler is already smart enough to tell you when you're using the language features that aren't compatible with the target runtime. For example:

error CS8701: Target runtime doesn't support default interface implementation.

There's always been language features that didn't work properly when combined with older framework versions with arguably less clear errors:

error CS8179: Predefined type 'System.ValueTuple`2' is not defined or imported

Why start caring now?

[PathogenDavid]

At the time, it needed to get in, and there was no API to understand the highest-supported language version for a given TFM.

Are you sure about that? I just tested this in 16.2.3 with the .NET Core 3.0 Preview 8 SDK installed and enabled (I know, not a supported combo.) If I target anything besides .NET Core 3.0, the C# 8.0 option disappears.

When targeting .NET Core 3.0:

When targeting .NET Core 2.2, .NET Core 1.0, .NET Framework 4.6, 4.7.2, etc...:

This is an SDK-style project, did not test legacy.

[cartermp]

What exactly are the data points meant to show?

Opening of the dialog.

I don't really understand the need for this restriction when the compiler is already smart enough to tell you when you're using the language features that aren't compatible with the target runtime.

As stated earlier, the feedback from users was that this was too confusing, so the decision was to make the lines rather clear. If you'd like to use C# 8 outside of .NET Core 3.0 or .NET Standard 2.1, please modify your project file or a Directory.build.props file.

Are you sure about that?

Yes. Previously, everything was just hard-coded and unable to cope with any changes (e.g., .NET 5 and C# 9 preview, any future changes, etc.).

[miloush]

Opening of the dialog.

So you disable the most useful feature in the dialog and then remove it on the basis that people don't use it?

[cartermp]

So you disable the most useful feature in the dialog and then remove it on the basis that people don't use it?

Firstly, I think this is an assumption you're making here. We have zero data about opening the dialog, interacting with it, or any correlation between someone's configuration and settings represented here. And the first release where we can put any kind of measurements of that nature is the 16.3. release. Usefulness of its contents _at large_ isn't known by anyone, hence the desire to have at least the basic data point of measuring opens.

Secondly, there's a decision around .NET Core 3 and beyond (see this blog post) that new features are only available on .NET Core. The reality is that a compiler works in terms of type shapes, and a subset of features can run just fine anywhere, so enabling it by default outside of .NET Core 3 and .NET Standard 2.1 means you only get a subset of things working. The lines were made more clear by setting defaults in tools and updating this UI. This was also decided to go into the product for the 16.3 release, as that corresponds to the release of .NET Core 3.

These aren't serial decisions. If enormous amounts of non-.NET Core developers seek to use C# 8 by using this dialog, they'll open it in the 16.3 release and we'll see that, since nothing has actually been released outside of previews yet (which bias more towards .NET Core developers anyways).

[miloush]

Okay so you are not actually interested in how much the dialog is used, you want to know how many non-.NET Core developers seek to use C# 8, specifically using this dialog.

You already made assumptions that lead to disabling the feature and API and you keep making assumptions about the use cases that ultimately result in no value of the data you will gather in regards of your questions. How will you distinguish users that opened the dialog to downgrade the language version? Furthermore, once a user finds out they can't use the dialog to perform the task, then they will never open it again, because they already know. You make them stop to do something as a result of trying to find out how often users do it.

Here is a way how to answer your question how many developers seek to use C# 8: Let the developers choose the language version and record how many people choose "C# 8.0".

[PathogenDavid]

As stated earlier, the feedback from users was that this was too confusing,

I must've missed this, but if that's the case I guess it makes sense to make selecting non-ideal framework/language version pairings less accessible. Not the ideal solution, but like you said there isn't a lot of time to do something better.

Yes. Previously, everything was just hard-coded and unable to cope with any changes (e.g., .NET 5 and C# 9 preview, any future changes, etc.).

Ah, I interpreted the situation as hard-coding was something that was considered but unacceptable rather than what was currently being done.

Thanks for clarifying things! This change really only impacts my workflow for quick one-off test projects, so I'll find a way to manage.

[sharwell]

I'm going to close this as External since Roslyn has no control over the situation. Please feel free to continue commenting and/or @cartermp can suggest an alternative location for the discussion.

[miloush]

@PathogenDavid

I must've missed this

For reference that was mentioned here: https://github.com/dotnet/roslyn/issues/38048#issuecomment-522845972

it makes sense to make selecting non-ideal framework/language version pairings less accessible

Not for the price that you disable all other pairings. You can also clearly state that not all language features are available (as it used to be the case all the time). That is, unless you are trying not to bias your data on how many people seek to use C# 8.

[cartermp]

Okay so you are not actually interested in how much the dialog is used, you want to know how many non-.NET Core developers seek to use C# 8, specifically using this dialog.

Nope, just how often it's opened. There's no way to distinguish based on what people _want_ to do, that's not a goal. But we can't just rely on data in previews since those bias heavily towards advanced users and those who experiment with things, so the ratio of users opening the dialog compared to total users is likely to be higher than how it is in released bits.

This digression won't really get anywhere though. The decision has been locked and is shipping for 16.3. I suggest queuing up feedback after it's been released if you'd like to see it reversed.

[miloush]

This digression won't really get anywhere though. The decision has been locked and is shipping for 16.3.

That I agree with. I was getting a bit frustrated by the research methodology here, apologies.