Preamble code for properties

[The-Futurist]

Occasionally I find myself wondering why we can't write stuff like this:

    public struct ODR
    {
        public BitVector32 AllBits;

        public bool this[int I]
        {
            if (I > 31)
               throw new ArgumentOutOfRangeException();

            get => AllBits[1 << I];
            set => AllBits[1 << I] = value;
        }
    }

Have some common code that runs irrespective of whether its a get or a set. Of course this is a rare case because this is a rare thing, a property that accepts an argument, but it would be neat if we could do it, some indexers also take multiple arguments as well.

[tacosontitan]

I don't see much use for such a feature outside of guard clauses, and I don't believe that properties should have behaviors (e.g. they shouldn't throw exceptions).

Can you give an example that isn't a guard clause that would more thoroughly demonstrate the usefulness of such a feature?

[HaloFour]

Occasionally I find myself wondering why we can't write stuff like this:

Probably because nobody has proposed for such code to have a meaning in the language.

The property itself is not a method, so one would have to define what it means to allow for statements to appear there outside of the accessor methods.

Allowing for arbitrary statements to exist within the property would probably conflict with property-scoped fields, which is a championed proposal.

[The-Futurist]

Can you give an example that isn't a guard clause that would more thoroughly demonstrate the usefulness of such a feature?

Not really, the use case is a guard, that's the impetus for the concept. I agree too that ordinarily properties should not throw, but if the index is invalid then throwing (in this admittedly limited case) is appropriate.

I'm creating lots of similar structures and so this is coming up as I write this stuff, I accept this is a narrow case but it can get unsightly adding the guard into every get/set when the code is otherwise very simple.

[CyrusNajmabadi]

This would likely conflict with property scoped scoped fields/locals. And I'm not sure how we'd feel about logic (not just state) both being expressible here and something which would run for both the getter and setter.

[The-Futurist]

It just seems ugly in this specific case, wanting to range check the index when the code looks very neat with simple structure like this:

            get => AllBits[1 << I];
            set => AllBits[1 << I] = value;

There might be other ways to address this, I only thought about it as a code block outside of get/set.

[The-Futurist]

An slightly better example of where this could be helpful is with stuff like this, an MCU register in which certain bits are reserved, not to be accessed (access indicates an error is callers logic).

We want to throw if any of these subscripts are passed: 15-12 and 10 (and of course anything greater than 15).

One could have a "subscript validator" function, as in here:

        public bool this[int I]
        {
            get => GetAsBitVector32(ref allBits)[BitSupport.VectorOf1Bit[Check(I, 15)]];
            set => GetAsBitVector32(ref allBits)[BitSupport.VectorOf1Bit[Check(I, 15)]] = value;
        }

Here it just throws if anything > 15 is used, but the flexibility needed in that functions signature to handle case like that example register, becomes a bit too much (though it is doable). Being able to write checking code "above" the get and set would feel natural. Perhaps I can devise a "Check" that just accepts a bitmask that represents legal or illegal bit positions...