[API Proposal]: Why can't access a constructor element using 'this'

[Mr0N]

Background and motivation

https://sharplab.io/#gist:5ec979cc565a8a49ed04f005f260c7e1
Why can't access a constructor element using 'this' ?

API Proposal

  class One(string one)
  {

      public void Start()
      {
          Console.WriteLine(one);
          //Console.WriteLine(this.one); //error

      }
  }

API Usage

Alternative Designs

Risks

[GalaxiaGuy]

Because they are parameters, not instance members:

https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/tutorials/primary-constructors#primary-constructors

It's important to view primary constructor parameters as parameters even though they are in scope throughout the class definition.

[Mr0N]

This is not true, with the help of the this keyword you can clearly say that the reference is not to the internal changes of the method.

[Mr0N]

Now it becomes very confusing code that is difficult to read. It is not clear what this is, this is a parameter, this is a public field from a class that this class inherits from, this is a change in a method.

[CyrusNajmabadi]

This is not true,

It is true. you cannot use this to distinguish between locals and parameters within a method or local function. Neither are members on the instance value.

[CyrusNajmabadi]

Now it becomes very confusing code that is difficult to read.

It's always been the case that distinguishing between parameters and locals was not possible at hte use site.

Again, if you want a feature to support that, feel free to suggest it. But right now, as these are just parametres, they behave hte same way parameters always have wrt to lookup, and they have that same limitation that has existed since c# 1.0.

[HaloFour]

Captures for lambdas and local functions are also typically implemented as fields, and you could never qualify them as such. That's the case even though the lambda body and captures are emitted in the same separate type. Just because the implementation detail is to emit a field doesn't mean that the language should treat them as such.

If you don't like it, you don't have to use the feature.

[Mr0N]

Because they are parameters, not instance members:

https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/tutorials/primary-constructors#primary-constructors

It's important to view primary constructor parameters as parameters even though they are in scope throughout the class definition.

[CyrusNajmabadi]

That is the compiled code, which is an implementation detail. THe language does not care how it is implemented, and the compiler is free to implement it in other ways (including not using a field).

[Mr0N]

And I understood that the studio somehow magically replaces these symbols <> with others. Why is it done this way?

[CyrusNajmabadi]

Because they are implementation details, not to be used/referenced by other code. We give 'mangled' names like these for all the things we generate as impl details.

[Mr0N]

and what does this mean, and if the class is large, and I add this field, the whole program will eventually break

[HaloFour]

I see what you're referring to. Yes, the compiler will prefer the field defined in the parent class over making a capture of the primary constructor parameter. This is a known behavior and discussed during design meetings.

[HaloFour]

Here is the part of the spec that discusses this: https://github.com/dotnet/csharplang/blob/main/proposals/csharp-12.0/primary-constructors.md#warn-on-shadowing-by-a-member-from-base

As you can see it does result in a warning.

[Mr0N]

why not an error?

[Mr0N]

How then to get information from the constructor, if there is a similar field

[HaloFour]

why not an error?

Because it's not illegal.

How then to get information from the constructor, if there is a similar field

Assign it explicitly to a field in an initializer.

[GalaxiaGuy]

The existence of a field is an implementation detail that the C# compiler can choose. The names are chosen to intentionally not collide with something a user can enter.

https://devblogs.microsoft.com/dotnet/check-out-csharp-12-preview/

For primary constructor parameters, the capture is implemented by generating a private backing field on the class or struct itself. The field has an “unspeakable” name, which means it will not collide with other naming and is not obvious via reflection.

Many C# features are implemented this way.

If you add a field with a same name, one will shadow the other. References to one in your example will refer to the field and not the parameter.

https://dotnetfiddle.net/QolwsW

[Mr0N]

this is where the problem turns out

[CyrusNajmabadi]

yes. the same happens with normal fields as well.

[Mr0N]

The existence of a field is an implementation detail that the C# compiler can choose. The names are chosen to intentionally not collide with something a user can enter.

https://devblogs.microsoft.com/dotnet/check-out-csharp-12-preview/

For primary constructor parameters, the capture is implemented by generating a private backing field on the class or struct itself. The field has an “unspeakable” name, which means it will not collide with other naming and is not obvious via reflection.

Many C# features are implemented this way.

If you add a field with a same name, one will shadow the other. References to one in your example will refer to the field and not the parameter.

https://dotnetfiddle.net/QolwsW

It's easier to simply restrict the user from entering a field identical to the primer in the constructor; it will help avoid potential issues

[Mr0N]

this is where the problem turns out

does

[Mr0N]

Such code becomes very difficult to read

using System;
using System.Web;

(new One(21) as Two).Start();
  class One(int one):Two(one)
 {
    public override void Start()
    {
        Console.WriteLine(one);
     //   base.Start();
    }
    private int one =7382;
 }
 class Two(int one)
 {
    public virtual void Start(){
    
        Console.WriteLine(one);
    }
 }

[Mr0N]

https://sharplab.io/#gist:a276efd01fb71475706fed5a53d63462
Why does the compiler change the variable name here?

[CyrusNajmabadi]

locals dont' have names in IL. What you're looking at is the arbitrary name the decompiler picked for you.

[HaloFour]

Primary constructor parameters are not members/fields, nor can they be accessed as members/fields. If they are used beyond the lifecycle of the constructor then they are captured, but how they are captured is an implementation detail. The fact that the implementation detail might use fields as storage isn't relevant to the language.

This behavior is intentional.

[Mr0N]

That is, according to the idea, it is not possible to get access to the fields of the constructor primer?

[HaloFour]

You access the captured parameters by their name. They are not members, so you can't reference them as members. There are no fields as far as the language is concerned.

[Mr0N]

At first glance, the fields seem like those in JavaScript, but without using "this."

[CyrusNajmabadi]

At first glance, the fields seem

These are not fields.

but without using "this."

Correct. They are not members. They are are parameters. They are not accessed off of 'this'

[Mr0N]

https://sharplab.io/#gist:1233568c9eea11dc36412dfdcb090d3e

How to understand where the information is being recorded here?

[HaloFour]

By reading the code? I don't know what your intent is from this rapid-fire picture show approach to trying to discuss the feature. The behaviors have been discussed during design reviews and publicly on this repository before the feature was shipped.

If you want to suggest new ways of prefixing/qualifying identifiers then do so. The warning exists to try to inform you of the fact that you have a parameter that shadows an accessible field.

[Mr0N]

How to read it, Base is a class of some kind of compiled assembly of downloaded from nuget

[HaloFour]

The compiler will warn about the shadowing regardless of where the base class is declared.

Beyond that, I don't know what you're asking. The questions around the behavior of the feature have been answered. If you don't like them, then you're welcome to open discussions around ways of changing them. However, as the feature has shipped, short of something drastic and unexpected it's unlikely that anything will change.