Proposal: Reduce get-only property's accessor body ceremony (TypeScript-fashioned)

[Rekkonnect]

Summary

Make the single accessor body of a property or indexer simplier to write without introducing ambiguity.

Motivation

Sometimes get-only properties or indexers need more than one line, so they can't be declared as expression-bodied (using =>). While they are designed to be properties as per the guidelines (trivial computation, no side-effects), it's simpler to use a method in their place, to avoid the extra nesting level introduced by the get accessor.

Consider the following real-world example:

public SolidColorBrush Brush
{
    get
    {
        if (Dispatcher.UIThread.CheckAccess())
        {
            _brush.Color = Color;
        }

        return _brush;
    }
}

The case here is the Brush property, which is a get-only property and could be declared as a method to avoid nesting the code one level deeper. We cannot use the ternary operator here, so this property will always be unnecessarily wrapped in one more set of braces.

Design

TypeScript has property bodies, which are methods declared by prepending a get or set in front of them, like so:

get myProperty(): boolean {
    return true;
}

This syntax can be inspired from by placing the accessor keyword in the signature. While TypeScript requires the parentheses despite never allowing arguments, it's only because they have to be declared as functions. In C# we have no such requirement, so we can safely omit that.

So an approach can be the following:

public SolidColorBrush get Brush
{
    if (Dispatcher.UIThread.CheckAccess())
    {
        _brush.Color = Color;
    }

    return _brush;
}

We place the get keyword in between the property's type and its name. This is not valid code right now, so it can be used.

The same approach can be followed to support explicitly implemented interface properties:

public SolidColorBrush get ILazilyUpdatedBrush.Brush
{
    if (Dispatcher.UIThread.CheckAccess())
    {
        _brush.Color = Color;
    }

    return _brush;
}

This can also extend to indexers, which might also be get-only, placing the get keyword between the return type and the this keyword, like so:

public SolidColorBrush get this[string key]
{
    var brush = _brushes[key];
    if (Dispatcher.UIThread.CheckAccess())
    {
        brush.Color = Color;
    }

    return brush;
}

Edges

The accessor's accessibility is always the property's accessibility, and can never be explicitly specified when the property only has one accessor, so nothing needs to be done in that area.

A non-partial property may only be declared in one of the two ways; with the traditional block-bodied accessor, or with the new syntax. The new syntax also supports the abstract, virtual, override, new and partial modifiers.

Partial properties may have their declaration part in either syntax and be implemented using the other, which won't be elaborated in this proposal.

Attributes on the property with no explicit target resolve to the property itself. The method and return targets are valid to use in the new syntax, resolving to the property's accessor and not the property itself.

Notes

Setters are not touched here. There might only be one case where using a setter-only property with a body makes sense over a method, and that is the indexer. An unrealistic example is below:

// Assume we have a hybrid dictionary using both a linear key index stored in a List<string>
// and the actual values in a fully materialized Dictionary<string, object>
public object this[string key]
{
    set
    {
        if (IsSmall() && !_linearIndex.Contains(key))
        {
            _linearIndex.Add(key);
        }
        _dictionary[key] = value;
    }
}

The above code could be then simplified to:

// Assume we have a hybrid dictionary using both a linear key index stored in a List<string>
// and the actual values in a fully materialized Dictionary<string, object>
public object set this[string key]
{
    if (IsSmall() && !_linearIndex.Contains(key))
    {
        _linearIndex.Add(key);
    }
    _dictionary[key] = value;
}

The proposal can be very easily extended to support setter-only properties, but it's intentionally left out of scope due to the high risk of enabling this declaration pattern.

[HaloFour]

public IReadOnlyList<Statement> ReplacedOrOriginal { get {
    if (IsNoOp)
    {
        return [Original];
    }

    return Replacements;
}}

[Rekkonnect]

Still one set of brackets more than the proposal, despite shortening the whitespace

[spydacarnage]

public IReadOnlyList<Statement> ReplacedOrOriginal => IsNoOp ? [Original] : Replacements;

[Rekkonnect]

public IReadOnlyList<Statement> ReplacedOrOriginal => IsNoOp ? [Original] : Replacements;

The original post mentions that alternative and elaborates on that

[Rekkonnect]

Updated the original post with a body that cannot be simplified to a ternary expression.

[IS4Code]

Just to ask the obvious, what is wrong with the natural approach?

public SolidColorBrush Brush => {
    if (Dispatcher.UIThread.CheckAccess())
    {
        _brush.Color = Color;
    }
    return _brush;
}

[timcassell]

That might work if we ever get expression blocks, but it would only cover the getter case, and not the setter.

[iam3yal]

@timcassell Well, they can always allow something like this but I doubt it...😄

public SolidColorBrush Brush[] => {
   // Do something with 'value'
}

Or

public set SolidColorBrush Brush => {
   // Do something with 'value'
}

[CyrusNajmabadi]

I would be fine with the former

[CyrusNajmabadi]

This would also fall out with expression blocks. So perhaps that's the best solution here.

[IS4Code]

Aren't there unsolved questions with expression blocks related to control statements? In this case, return or even yield should work normally, but I am not sure how they would be interpreted as a part of an expression block.

[jnm2]

This addresses something that has bothered me for a while, too. Often with multi-statement lazy init. It's not the indentation and braces per se that I dislike, but rather the fact that the get line is not busy enough to justify itself and the indentation and braces all together.

Syntax bikeshed:

public SolidColorBrush Brush.get
{
    // ...
}

public object this[string key].get
{
    // ...
}

[RikkiGibson]

.get I find fairly convincing because it's how symbol display already shows the accessor.

[RikkiGibson]

Also, should public SolidColorBrush Brush.get; represent a getter-only auto property declaration?

[jnm2]

With an initializer, I could see the auto prop form being very easy to mistake with =>.