Evaluating record properties only once

[nkosi23]

Has there been a proposal to enable evaluating record properties only once as explained here:

https://stackoverflow.com/questions/2873125/f-record-member-evaluation

I am not able to find one, but i find it surprising so i suspect i may not be using the right search terms.

Sometimes, read only properties of records may do relatively expensive computations, and if you are doing aggregations accessing these properties multiple times on large number of records, this computation time may start to matter.

My idea would be to add a keyword to record member declaration to indicate that the member should only be evaluated once. Could be as easy as making the compiler create a backing field, and move the body of the expression to the constructor of the record.

Or alternatively we could also allow the let keyword in the context of record, to indicate that the member is a public field that will only be evaluated once. But this approach sounds more complex.

[Tarmil]

My idea would be to add a keyword to record member declaration to indicate that the member should only be evaluated once. Could be as easy as making the compiler create a backing field, and move the body of the expression to the constructor of the record.

Actually there's no need to invent a new keyword, it already exists (for classes): member val. So this proposal could be summarised as "Allow member val on records".

An inconvenient is that this would turn { x = 1 } and { a with x = 1 } into potentially expensive operations, which I'm not a fan of.

[nkosi23]

Thanks! But doesn't val imply mutability? By the way, thanks a lot for your deserializarion library. It has been a lifeline for me.

[Tarmil]

member val isn't necessarily mutable; only if accompanied by with get, set.

[jwosty]

An inconvenient is that this would turn { x = 1 } and { a with x = 1 } into potentially expensive operations, which I'm not a fan of.

@Tarmil Expensive how? In terms of making the object itself take up more memory (for the field storage)? Or are you more referring to the fact that it would kick off some additional "invisible" computations? If the latter, I wouldn't personally find that much more unexpected than C# constructors potentially doing "expensive" things. But I could see how one would

[T-Gro]

I think the added cost would come from moving the work from being on-demand (as it is now for member) to being eagerly invoked at construction.

[T-Gro]

I think there are more options on how to accomplish this goal, and the language does not need another one:

• member val for classes
• let cachedField = for classes
• { X : Lazy<...> }
• Make the calculated value part of the record and provide a static member (or a module function) to construct it and do the computation

Do we perhaps need more explicit docs about member x.ABC = ... properties being executed every time by design?

Another angle, often times it is demanding to re-evaluate every time even if the caching would be automatic (e.g. computing .Age from Birthday and current day etc.). Which is why the mentioned alternatives make the value storage explicit, to make a visible difference between stored data and computation.

[nkosi23]

Thanks, I see where you're coming from! Using classes would change equality semantics so this is a substantial drawback. The lazy approach changes the API; in some cases this can be acceptable and even desirable, but in the general case this gets in the way of what people truly want to achieve. Then explicitly storing the value in the record with a static constructor solves the problem but introduces others (see below) and introduces boilerplate for what is a common use case.

These other approaches are not solutions but workarounds in my opinion. My thinking is that since F# already generates plenty of helpful code, it would be very relevant to optimize this use case that i personally meet extremely often as i design my domain models. Right now, the attitude i have is that the performance hit of computing the property every time it is accessed is negligible. But I'm uncomfortable.

There is also a major issue that just came to my mind with the two last workarounds that only built-in support can really solve: if the copy and update expression is used to modify other fields, the value of the calculated field will be wrong, which is a major gotcha. If copy and update copies by reference, the issue also applies to the lazy approach if the value has already been evaluated (which would lead to nasty debugging sessions). Moreover someone can modify the value of one of the computed fields directly and set it to an invalid value. By making these fields read-only members, this is not possible and the code/API is self-documenting.

Also from a "marketing" perspective, since F# promotes immutability by default, it is very surprising that properties are executed every time and that this use case is not supported by the language. I've seen quite a couple of people surprised by that. I was personally shipping code in production for quite a while believing that this was the case. So yeah, I agree that a warning in the docs would be helpful!

[nkosi23]

I have opened this issue.