Wait, wait, since when can you put the default assignment right there on the same line? Go ahead, say since always... I dare you.
Edit: Apparently this came in C# 6.0 (July, 2015). Ok, now I don't feel so bad. :-)
On a separate note, C# might not sexy or even that popular, but I really enjoy coding in it, and the continuing evolution of the syntax is a joy.
Though I doubt this makes a ton of real world impact, performance wise. Stripping names would do more to shrink the .Net code.
And if you wanted a publically read-only/privately mutable value without properties you'd have to write ... a field and one method. Possibly two methods if you wanted some shared validation code everywhere you assign the field.
Like I said, in practice, it's the same. If you have some case where three vs. two members makes a difference you're in pathological case territory.
public double Area
{
get { return Width * Height; }
set
{
Width = Math.Sqrt(value);
Height = Width;
}
}
public double Area => Width * Height;Have they introducted willSet and didSet too?
Neat stuff, i may try the language out in a future project on windows.
[1] https://msdn.microsoft.com/en-us/library/system.componentmod...
[2] https://msdn.microsoft.com/en-us/library/system.componentmod...
Auto-properties in C# are one line of code, same as fields, and the getter/setter methods should always be inlined which turn them into field accesses anyway. So I'm not sure how that would affect compile times or lead to slower code in anything but some pathological use case. Or DEBUG, but at that point all performance bets are off.
(Technically Microsoft can get worse performance on properties vs. fields when using NGen - that's why they have TargetedPatchingOptOutAttribute - but that doesn't apply to regular, non-Framework assemblies.)
As for code bloat `public int SomeValue { get; private set; } = 6;` encapsulates a publically read-only/privately mutable property with a default value quite concisely...