Maybe I wasn't clear enough. When I said > To bridge the gap you would need to wrap the API with some construct that make the identity immutable.
I meant something along the lines of Brian's method. My toy example was to demonstrate another possible solution to how to solve the issue at language level *if we were to decide this is were it should be solved there*. I do not wish to put this idea as a suggestion for a language improvement. Holo The Wise Wolf Of Yoitsu On Mon, 26 Jan 2026, 21:04 Mahied Maruf, <[email protected]> wrote: > > Holo The Sage Wolf says: > > It seems like the problem is the flexibility combined with the ease of > use. > > > > Fundamentally, if you represent *mutation* using records you are bound to > > have mismatches between different levels of the application. > > I think it's important to understand this semantic distinction > properly. You proposed a syntax to prevent derivation of an existing > record if the identifier was changed, but to me this seems also like a > case that could make sense and enforcement of it should be part of the > database layer (ORM etc). Brian proposed that a seperate class > (or record) could be used just for the identifier and I both agree > with this mental model and am already seeing it being done in e.g. > representation of concatenated primary key where it already is much > more intuitive to perform validation (among other things) this way. > > Best regards, > Mahied Maruf <[email protected]> >
