Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

C# /langversion:3 handles closures in foreach loops like /langversion:5 #8034

Closed
binki opened this issue Jan 19, 2016 · 1 comment
Closed
Labels
Area-Compilers Resolution-By Design The behavior reported in the issue matches the current design
Milestone

Comments

@binki
Copy link

binki commented Jan 19, 2016

C:\Users\ohnob\Documents\Visual Studio 2015\Projects\ConsoleApplication9>PROMPT ^>

>cat Program.cs
using System;
using System.Collections.Generic;
using System.Linq;

public class Program
{
    public static void Main()
    {
        var closures = new List<Action>();
        foreach (var i in Enumerable.Range(0, 10))
            closures.Add(() => Console.WriteLine(i));
        foreach (var closure in closures)
            closure();
    }
}

>packages\Microsoft.Net.Compilers.1.2.0-beta1-20160108-01\tools\csc.exe /langversion:3 /out:Program.exe Program.cs
Microsoft (R) Visual C# Compiler version 1.2.0.60108
Copyright (C) Microsoft Corporation. All rights reserved.


>.\Program.exe
0
1
2
3
4
5
6
7
8
9

>

I was expecting all lines to output 10 if Eric Lippert’s comment on how this behavior changes in C#-5.0 are accurate.

It seems weird to me that the compiler claims to support langversions less than 5 when it won’t change such a breaking behavior as this. There are other examples of when setting /langversion behaves like the latest compiler rather than an older one, please let me know if I should file issues like this when I notice them.

@gafter
Copy link
Member

gafter commented Jan 20, 2016

Yeah, this is intentional. the /langversion switch mainly affects the syntax recognized by the compiler, not the semantics.

@gafter gafter closed this as completed Jan 20, 2016
@gafter gafter added the Resolution-By Design The behavior reported in the issue matches the current design label Jan 20, 2016
@gafter gafter added this to the 1.2 milestone Jan 20, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Compilers Resolution-By Design The behavior reported in the issue matches the current design
Projects
None yet
Development

No branches or pull requests

2 participants