C#

Richard Deeming wrote:

String interpolation; pattern matching; the enhanced "switch" statement; the null-conditional operator - they all compile to IL that will work on older framework versions.

Richard Deeming wrote:

And some changes require additional changes to the CLR or the BCL. But those tend to be quite rare, because the language team are reluctant to make those kinds of changes.

Bastard Programmer from Hell
If you can't read my code, try converting it here[^]

jschell wrote:

All three methods require a comparison for every access of the property.

jschell wrote:

Since it should always be defined then the set semantics and ctors should define that rather than the get.

Bastard Programmer from Hell
If you can't read my code, try converting it here[^]

Eddy Vluggen wrote:

Nah, a property that defines a getter is going to return a value, and in the exceptional case of an error it will raise an exception. Which parts of those semantics are unclear?

jschell wrote:

I was suggesting that the ctor or other usages in the class should insure that the attribute always has a value.

If a setter was added then that too should insure that a value always exists.

jschell wrote:

And that would be more efficient.

Bastard Programmer from Hell
If you can't read my code, try converting it here[^]

Eddy Vluggen wrote:

So, instead of testing in the getter, you apply this in ctor, other useages, and the setter? Why, is it more DRY than putting that test in the getter?

Eddy Vluggen wrote:

That wouldn't be very lazy though, defeating the original purpose.

public class MyClass
{
  public MyClass()
  {
    // I find this statement below confusing and prone to refactoring error
    E = new object(); 
  }
  /*
  * more than 10 lines of code
  * ....
  * ....
  * to make thing a little bit less clear
  */
  public object A { get; set; }
  public object B { get; set; }
  public object C { get; set; }
  public object D { get; set; }
  public object E { get; private set; }
  public object F { get; set; }
  public object G { get; set; }
  public object H { get; set; }
}

public object E { get; }

private readonly object _E = new object();
public object E  => _E;

Quote:

warning CS0649: Field 'MyClass._E' is never assigned to, and will always have its default value null

public object A { get; } = new object();

Bernhard Hiller wrote:

that's not possible with properties, even when they have no explicit setter

internal object _field = null;

public object Field
{
    get
    {
       return _field;
    }
}

public void SetField(object ofield)
{
   _field = ofield;
}

Super Lloyd wrote:

Did you miss something Bill?

private List<DateTime> _someList = null;

public List<DateTime> SomeList
{
    get
    {
        _someList = _someList ?? new List<DateTime>();
        return _someList;
    }
}

public object GetExpensiveAndNonNullObject()
{
  if (expensiveObjectBasedOnPrivateState == null)
    expensiveObjectBasedOnPrivateState = new object();
  return expensiveObjectBasedOnPrivateState;
}
object expensiveObjectBasedOnPrivateState;

public object GetExpensiveAndNonNullObject()
{
  expensiveObjectBasedOnPrivateState = expensiveObjectBasedOnPrivateState ?? new object();
  return expensiveObjectBasedOnPrivateState;
}
object expensiveObjectBasedOnPrivateState;

public object GetExpensiveAndNonNullObject()
{
  return expensiveObjectBasedOnPrivateState ?? (expensiveObjectBasedOnPrivateState = new object());
}
object expensiveObjectBasedOnPrivateState;

Super Lloyd wrote:

return field ?? (field = Create());

Sascha Lefèvre wrote:

I try to avoid making use of the expression-character of an assignment.