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

Compiler does no longer report local variable scope conflict #38377

Closed
Suchiman opened this issue Aug 29, 2019 · 8 comments
Closed

Compiler does no longer report local variable scope conflict #38377

Suchiman opened this issue Aug 29, 2019 · 8 comments
Assignees
Labels
Area-Compilers Bug Documentation Resolution-By Design The behavior reported in the issue matches the current design
Milestone

Comments

@Suchiman
Copy link
Contributor

Suchiman commented Aug 29, 2019

Version Used: 16.3 Preview 2

Steps to Reproduce:
I don't know if this is an expected new feature or not, i've noticed because it broke on the build server (having only 16.2.3 installed) and my .NET Framework project is set to Language version Automatically selected based on framework version (7.3).
Sharplab

using System;
using System.Collections.Generic;
using System.Linq;

public class C
{
    public List<string> Values = new List<string>();
    
    public void M(IEnumerable<C> source) 
    {
        source.Where(x => x.Values.Any(x => x == "Hello World"));
    }
}

Expected Behavior:

error CS0136: A local or parameter named 'x' cannot be declared in this scope because that name is used in an enclosing local scope to define a local or parameter

Actual Behavior:
Compiles fine

@alrz
Copy link
Member

alrz commented Aug 29, 2019

afaik this is a new feature in C# 8.0, local function and lambda parameters can shadow outer names.

@gafter
Copy link
Member

gafter commented Aug 29, 2019

If this is not documented in https://github.com/dotnet/csharplang/tree/master/proposals/csharp-8.0 then this is a (documentation) bug.

@Sliptory
Copy link
Contributor

Sliptory commented Oct 5, 2019

I could reproduce this error only in the project collected on .NET Core 3.0
An error is generated on the NET Framework 4.7.2.

@svick
Copy link
Contributor

svick commented Oct 6, 2019

@Sliptory I think that's because it's a C# 8.0 feature and .Net Framework projects default to C# 7.3.

@BillWagner
Copy link
Member

@gafter The only mention I can find for this is in #1565

I don't see a proposal doc for local static functions, which is where I would expect this.

@jcouv Does something exist that should be added?

@gafter
Copy link
Member

gafter commented Oct 7, 2019

@BillWagner You're right, there is no proposal document for this. The compiler/languages team has not made it a priority to maintain formal specs for the features we develop.

As best I understand the current plan, we're depending on you to provide user docs for features.

@BillWagner
Copy link
Member

BillWagner commented Oct 7, 2019

@gafter 🤣

Do you want to move this issue to dotnet/csharplang and assign it to me?

Or, if @jaredpar adds me as a contributor on this repo, just start assigning these to me.

@gafter gafter moved this from Documentation to Active Work in Compiler: Gafter Oct 25, 2019
@gafter gafter modified the milestones: 16.4, 16.5 Oct 29, 2019
@gafter gafter moved this from Active Work to Specification Work in Compiler: Gafter Oct 29, 2019
@gafter gafter modified the milestones: 16.5, 16.6 Jan 16, 2020
@gafter
Copy link
Member

gafter commented Mar 16, 2020

There is a placeholder for a specification for this at: https://github.com/dotnet/csharplang/blob/master/proposals/csharp-8.0/shadowing-in-nested-functions.md

In short, this is by design.

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

No branches or pull requests

6 participants