[miamibougie]

Wouldn't these use-cases be better solved by public accessor methods though? I really liked the idea at first blush too, but the more I thought about it, the more I came around to the fact that it's ultimately the class maintainer's responsibility to ensure that the directives in those comments are followed safely. In cases like your first example, it's dangerous not just for the x reference of foo.state, but also any other concurrent references to the object, to perform modifications at all.

Maybe a read-only version, so you can grep state at a point in time?

[wgd]

> it's ultimately the class maintainer's responsibility

It's ultimately the responsibility of the programmer who's building a tool/product/etc, because everything is ultimately their responsibility.

As programmers we ~always have the nuclear option available to us of forking the code and implementing all the necessary accessors ourselves, but sometimes that's really just a bunch of pointless busywork and there's no reason we should have to put up with it in those cases.

This can be a contentious subject because there's a lot of nuance and the right answer is often context-dependent. But I personally think that the Java style of "we must absolutely protect the library user from themselves and childproof everything" is waaaay too far in the wrong direction.

I would much rather that a language have mechanisms to clearly communicate "don't touch this unless you have a good reason, but if you need to here's how" rather than saying in effect "you, the person using this library, are dumb and need to be prevented from messing with the library maintainer's perfect vision".

And so I think the "required acknowledgement" thing has the glimmer of a really neat innovation in it (although if I were to copy the idea for a language of my own I would probably make it obligatory, such that every struct allows breakglass access to private fields with a default acknowledgement, and all the library author can do is change the acknowledgement text).

[to11mtm]

> This can be a contentious subject because there's a lot of nuance and the right answer is often context-dependent. But I personally think that the Java style of "we must absolutely protect the library user from themselves and childproof everything" is waaaay too far in the wrong direction.

I tend to agree with this sentiment; especially when the 'child-proofing' means to do the thing right with the library/api in question is more work than just rolling your own.

> I would much rather that a language have mechanisms to clearly communicate "don't touch this unless you have a good reason, but if you need to here's how" rather than saying in effect "you, the person using this library, are dumb and need to be prevented from messing with the library maintainer's perfect vision".

In some cases I've seen/used the term 'Unsafe'.

C# language-ext uses this for some methods that can return null (as opposed to un-Unsafe-suffixed methods, which will throw on null). I've also used it for some 'low level' methods in libraries, where it is a case of 'you need to read the docs to know how to not turn it into a footgun'.

The problem of course is that in my main language (C#), the word 'unsafe' has other connotations (i.e. pointer arithmetic.)

When I first submitted my PR, there were numerous developers who did not like the term 'Unsafe' for the reasons mentioned above. I asked what it should have been called in that context instead, and floated 'Yolo' as a tongue-in-cheek suggestion.

(That being said, If there -was- a word to use to denote 'with great power comes with great responsibility' people would suggest, I'd love to hear it.)

[ianbutler]

I'd put forth dangerous, which is a synonym to unsafe but not a common keyword.