Repository navigation
Proposal: Property-Scoped Fields #133
Description
Activity
- changed the title
[-]Property-Scoped Fields[/-][+]Proposal: Property-Scoped Fields[/+]on Feb 17, 2017 Overall, I like this. Would it be reasonable to implement this so that we have both property scoped fields and also the automatic backing field?
For simple cases, such as properties that just need to implement
INotifyPropertyChangewe don't need to declare the field ourselves:public string MyProperty { get { return field; } set { field = value; NotifyOfPropertyChange(nameof(MyProperty)); } }
For more complex scenarios, we can declare our own local property scoped field:
public string MyProperty { string myField; get { return myField; } set { myField = value; NotifyOfPropertyChange(nameof(MyProperty)); } }
Should a property-scoped field be allowed to have the same name as another class member?
Yes, I think so. Would this really be any different than having a variable defined inside a method having the same name as variable defined outside the method?
Reacted by Joseph Musser, Thaina, Adrian, Nicklas, Mrxx99, Michael Hawker, Néstor Sánchez A., Vladislav Richter, Eduardo Larios, Adam Coulter and 6 moreTotally agree
But I would disagree to allow name collision. It should not collide with any other field
this.can be used to access class members which are hidden by locals. Presumably it would also be used for property-scoped field access. But if name collisions were allowed, then it would be possible to have property-scoped fields which are inaccessible when hidden by locals (or, a different keyword or syntax would be needed to access them).Reacted by Phillip K., Nicklas, Yan and Cole Tobin@scottdorman I guess that for simple scenarios and probably even complex ones you could use source generators for this so you wouldn't have to do that manually.
[NPCGenerator] public string MyProperty { get; set; }@eyalsk But not everybody has those generators by hand, especially when reading foreign code.
I would also disagree to allow name collision, with the exception of modifying a local 'new'.
public string MyProperty { string myField; get => { new int myField; /* why should you do this, it doesn't make sense, but it assures that you know what you do */ } set => myField = value; }
All good arguments, I think, for not allowing the name collisions. I'm changing my vote to "a property-scoped field should not be allowed to have the same name as another class member."
@eyalsk Yes, a code generator would work but not everyone can (or wants to) use them. Personally, I think access to the backing field of an autoprop should have been there from the start. Also, code generators aren't necessarily reasonable for all scenarios where I'd want access to the backing field. A few examples of that is doing complex validity checks on the value before setting it or setting the property has side-effects of setting some other read-only properties (think about splitting a full name property up in to first and last name).
In the current C# 7 preview in Local Functions (see here) when you re-declare a local variable you will get the following error:
A local or parameter named 'localVariable' cannot be declared in this scope because that name is used in an enclosing local scope to define a local or parameter (ERR 0136)
static void Main(string[] args) { var localVariable = 12; void LocalFunction() { var localVariable = 12; // ERROR, duplicate declaration } }
The same error could be issued when using a property scoped local - where the whole property is the enclosing scope, thus eliminating any further confusions or needs for extra keywords to access them (the outer variable, not the confusion 😉).
Reacted by Bevan Arps, Eik Rentzow, Nicklas, Antonia and Yan@scottdorman, @lachbaer Im not sure I understand you because it would probably be just a
Install-Package <SomePackage>away.I like the original proposal but I think that the amount of ways that you can construct properties today is overwhelming so going further with it and add more ways is just taking properties to the extreme. :)
@scottdorman I think that you need to create a new proposal for it, any sub topic should have its own proposal.
I think it's fine for two property-scoped fields to share the same name, but not for a property-scoped field to share the same name as another top-level member:
// good public class FizzBuzz { public string Fizz { string field; get => field; set => field = value; } public string Buzz { string field; get => field; set => field = value; } } // bad public class FizzBuzz { private string field; public string Fizz { get => field; set => field = value; } public string Buzz { string field; // CS0102 get => field; set => field = value; } }
I'm not a fan of partially-auto-implemented properties. With expression-bodied accessors much of the syntactic boilerplate is already eliminated. Having to declare an explicit fields seems reasonable, especially in the case of dealing with calculated values (e.g. name parsing).
Reacted by Thaina, Eyal, Bevan Arps, FredyFerrari, Pent Ploompuu, Misa Jovanovic, Jim Przybylinski, Antonia and YanIf there is only one field needed for the primary use as backing field, I suggest an additional syntax, borrowed from C
struct:public string FirstName { get => _name; set => _name = value; } _name;
_nameis by definitionprivateto it's type (maybe unless directly prepended by an access modifier?).
OR, appropriate for this proposal, just scoped to the corresponding property.The advantage of this syntax would serve 2 purposes:
-
no need to explicitly state the type of the property (again)
-
This would also be in favor of Proposal:
fieldkeyword in properties #140, Semi-Auto-Properties, because that named backing field would expunge the need for afieldkeyword:
public string FirstName { get; set => _name = value; } _name = "(not set)";
or even shorter, in case expression-bodied
setof semi-auto-properties expect a value being returnd to assign to the backing-field:public string FirstName { get; set => value; } _name = "(not set)";
-
39 remaining items
I think one thing that could make this proposal much more useful would be to lift the limitation on the property-scoped field initializer and allow it to access instance members. That would enable scenarios like this following:
public int LazyProp { Lazy<int> lazy = new Lazy<int>(ExpensiveComputation); get => lazy.Value; }
Even better if the property-scoped field could be treated like a static local of sorts and can have its type inferred by the initializer:
public int LazyProp { var lazy = new Lazy<int>(ExpensiveComputation); get => lazy.Value; }
This also feels like a stepping-stone towards delegated properties and could simplify a number of AOP-like scenarios.
Reacted by Brandon Bonds, Oliver Brown, Christopher Watford, Jyrki Vesterinen, MizMahem, Yan and HopefulFrogHow would the event be raised in this scenario? If an event defines the add/remove, the current convention is that the underlying field is used to raise the event, not the event itself.
I think a solution would be to add a new accessor to events -get:public event EventHandler Foo { EventHandler foo; get => foo; add => foo += value; remove => foo -= value; }
@jnm2 Actually, the problem with your solution is this:
bool _active, _dead; public event EventHandler Foo { EventHandler fooActive, fooInactive; add { if(!this._dead) { if(this._active) fooActive += value; else fooInactive += value; } } remove { if(!this._dead) { if(this._active) fooActive -= value; else fooInactive -= value; } } }
What would
this.Foo(this, EventArgs.Empty)raise in this case?I'd rather a
raiseaccessor than agetaccessor. Agetaccessor would leak the details of the underlying publisher, which might not even be a delegate of the type of the event. Araiseaccessor would hide that detail behind a method of a signature matching that delegate.That assumes that scoped fields make sense in the case of events, and I'm not really sure that they do. It's extremely niche to explicitly implement an event as it is.
Reacted by Mr. TA, FaustVX, Petr Onderka, Joe4evr and YanIs there a way to vote to advance this proposition? So often I have felt guilty about creating private fields that should never be manipulated outside of Property accessors. I know it's wrong to put them in scope to trip up a maintainer, but the language currently gives us no alternative!
Reacted by Oasin Lyu, pikoslav, Alex, Weihan Li and Kot@CharlesJenkins Yes. Vote here:
@CharlesJenkins Yes. Vote here:
Thanks! I hope I got the right one.
- locked and limited conversation to collaborators
on Nov 19, 2024
Property-Scoped Fields
(Ported from dotnet/roslyn#850)
Summary
Allow fields to be scoped within the accessor body of a property or event declaration.
Motivation
Properties often encapsulate constraints on field access or ensure that certain behaviors are invoked. Sometimes it is appropriate for all field access to be performed through the property, including those from within the same class.
These constraints may be unclear or forgotten, leading to subtle bugs during maintenance which are often difficult to diagnose.
Scoping fields to the body of their property/event would allow the designer to more effectively communicate this intent to encapsulate.
Detailed design
Property-scoped fields may be defined above the accessor list within the body of a property or event:
myFieldandhandlerare encapsulated within their respective property/event. In each case, both accessors may directly reference the fields. Nothing outside of the property/event scope has direct access to those fields.Implementation comments from @CyrusNajmabadi:
Alternatives
Automatic backing field
This implementation would be an extension of automatic properties. The backing field could be accessed through a keyword
field, but only within the scope of the property/event:This would not allow multiple fields to be encapsulated in the same property.
dotnet/roslyn#7614 has a similar proposal with a different keyword (
$state).Auto-property syntax for custom setter/getter logic
dotnet/roslyn#1551
Semi-auto-properties with setters
dotnet/roslyn#8364
Class-scoped blocks for fields / explicit field usage
dotnet/roslyn#12361
Unresolved questions
A list of questions from @CyrusNajmabadi:
Syntax
It was noted that adding fields above accessors or below accessors (but not interspersed) could be an easier change to the existing compiler design. @lachbaer provided a potential design which would not be a breaking change to the API:
Field name collisions
Should a property-scoped field be allowed to have the same name as another class member?
Should local identifiers within accessors be allowed to have the same name as a property-scoped field?
Design Meetings