-
Notifications
You must be signed in to change notification settings - Fork 4k
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
Proposal: ?= Assignment operator #12606
Comments
This is a duplicate of #10249, only with slightly different syntax ( |
I agree that it is a duplicate of #10249. But I think it is a common pattern for lazy initialization : the "verbose" way : string name;
public string Name{
get{
if(name == null)
name = $"{firstName} {lastName}";
return name;
}
} Lazy<> class & C# 6 syntax can't help when firstName & lastName are instance members : public string Name{ get; } = $"{firstName} {lastName}"; compiler output : |
Unlike every other similar operator, the right hand side wouldn't get evaluated sometimes, which is pretty strange. Also both assignment (
Or decide overloading
|
I don't disagree. But you're not required to use the "verbose" syntax from your example. You can do the following: string name;
public string Name {
get {
return (name = name ?? $"{firstName} {lastName}");
}
} |
I can imagine that with source generators that it would be pretty easy to construct a way to declare a "lazy" read-only property without requiring any modifications to the language. It'd also be more capable since it would be possible to cater the implementation based on metadata, such as setting a concurrency policy: [LazyProperty(LazyThreadSafetyMode.ExecutionAndPublication)]
public string Name {
get { return $"{firstName} {lastName}"; }
}
// generates something like
private readonly object Name_Lock = new object();
private string string Name_Result = null;
private volatile bool Name_Published = false;
public replace string Name {
get {
if (Name_Published) {
return Name_Result;
}
lock (Name_Lock) {
if (Name_Published) {
return Name_Result;
}
Name_Result = original;
Name_Published = true;
}
}
} |
Surely the lazy initialisation method used in the OP: public string Name{
get{
return name = name?? $"{firstName} {lastName}";
}
} causes public string Name => name ?? (name = $"{firstName} {lastName}"); To my mind at least, this actually seems clearer than using the proposed |
@DavidArno great proposal, I omited the C# 6 property-getter |
Strong proponent of ?= Every time I want to resolve a null to a practical default I have to use elaborate notation. Introducing the ?= operator also prevents the coding error I like DavidArno's suggestion for a better readable and better performing version without any language changes: instead of:
Use:
I did not even think of that syntax. Yet, my mind still craves a ?= operator. Realizing that other people would also not think of DavidArno's syntax, introducing the ?= operator could under the hood execute the (possibly) more performant version of DavidArno, upping the performance of everybody's null-resolutions. I get the arguments of bbarry regarding the compiler implementation and consistency with behavior of other operators. Perhaps one could make it easier on him or herself and ignore the issues. No operator overloading, no making a problem out of the right hand side not always being executed, or differences with for instance the &=, & and && operators' behavior. Let the compiler translate x ?= y to x ?? (x = y), and leave the rest up to the same code that already handles all the intricate issues with the ?? operator, so all the issues with get solved for both syntaxes. |
I would thumbs-up except that |
@jnm2 Except for |
No, they're assignment operator versions of |
Not only is @HaloFour correct, I have long wished for the non-existent assignment versions of && and ||. |
One solution to this is to adopt the "treat variables as immutable" mentality, then the need for |
@DavidArno unless that's just not what I want to do. I prefer mutability and |
Moved to dotnet/csharplang#34 |
Summary
New
?=
operatorUsage
Before
After
The text was updated successfully, but these errors were encountered: