C#

Super Lloyd wrote:

that stupid comment.

Eddy Vluggen wrote:

The second third* won't, ever.

IL_0000:  ldarg.0     
IL_0001:  ldfld       Foo.field
IL_0006:  brtrue.s    IL_0014
IL_0008:  ldarg.0     
IL_0009:  ldarg.0     
IL_000A:  call        Foo.Create
IL_000F:  stfld       Foo.field
IL_0014:  ldarg.0     
IL_0015:  ldfld       Foo.field
IL_001A:  ret         

IL_0000:  ldarg.0     
IL_0001:  ldfld       Foo.field
IL_0006:  dup         
IL_0007:  brtrue.s    IL_0019
IL_0009:  pop         
IL_000A:  ldarg.0     
IL_000B:  ldarg.0     
IL_000C:  call        Foo.Create
IL_0011:  dup         
IL_0012:  stloc.0     
IL_0013:  stfld       Foo.field
IL_0018:  ldloc.0     
IL_0019:  ret         

object temp = field;
if (temp == null)
{
    temp = Create();
    field = temp;
}

return temp;

Richard Deeming wrote:

Yes it will. It's syntactical sugar; so long as the compiler supports it, the compiled code would run on .NET 1.0 if you wanted to

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

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;
    }
}