Sure. I have a Profile. Let's say I load it from the database and make a change. I want to know if I need to save the profile. This is particularly important when using optimistic locking, a.k.a. resource versioning. My profile has a version number, like an ETag. I only want to update if there is a real change, and updating increases that revision number with every persist.
Here's a scenario. A woman gets married. Her last name changes. She updates the profile from Smith to Jones. The last name is now dirty. The code that save the object can say, "Are you dirty?" The struct says, "Yup". Saving code says, "Right! In you go." On the other side, the bit gets flipped back to false (it's cleaned). At the end, the revision updates by one and goes back to the client.
Another scenario. A user opens the edit profile box, doesn't change anything, but hits save. Without a dirty check, the object, which hasn't fundamentally change, gets saved with a new revision number.
Now what is all this about the revision number? I don't want to allow changes to a profile whose revision number is greater than the revision number my client passes. Let's say the Profile has revision 5. The client, which has been disconnected for a bit, says, "Update the profile, at revision 2, with all this new great data." The system needs to reject that update. The client needs to tell the user, "Sorry. That didn't work. Here's all this new data." If the client is especially Canadian, it will also say, "Oh, by the way we've saved your data, would you like us to copy it over the new data". I've never seen Canadian code, and mine is especially Floridian, but it could happen like that.
All of this is fairly easy in OO languages, which Go is not. It's actually easy in Go too if you use -ters and Setters (Go doesn't like GetFirstName(), but is okay with FirstName()). If I use functions attached to structs, easy. Just curious how other feel about this.