Clarify semantics of write-only properties

[sylbeth]

As pointed out by @ttencate in #1261 (comment), there are use cases for write-only properties:

• Setting a password, which is immediately hashed so it can never be recovered.
• Setting a seed on a random number generator, which becomes meaningless after changing the RNG state.

These two cases can be easily done through methods, but to be fair, so can PhantomVar, but PhantomVar allows to write exported properties and link the methods together in the documentation, apart from having the very neat GDScript shorthand of calling the property or assigning to it. I believe specifically the seed one would be useful to export it for testing.

As of right now, Godot does not support write-only exported properties, generating for them a getter that returns null. I believe we can do better by generating a custom getter that returns the same as the Godot one but pushes an error or a warning. Although this could also be handled by Godot, I suppose. In any case, I thought it would be better to leave this in writing in its own issue.

[ttencate]

Thanks for opening this issue. It's good to discuss this separately.

For the record, I think gdext already "supports" write-only #[var]s, so long as they're not PhantomVar, where I explicitly forbade it because the semantics were unclear, and I could do so without breaking backwards compat.

PhantomVar allows to write exported properties and link the methods together in the documentation

There is only one method though: the setter. Nothing to link.

apart from having the very neat GDScript shorthand of calling the property

What do you mean by "calling the property"? A property that is Callable but write-only can still not be called.

or assigning to it

I actually think the method syntax is better. Assigning to a property suggests that you can get the value back using the same syntax, but you can't. When I see user.password = pwd, I would think I can subsequently do print(user.password), but I can't. Worse, GDScript will happily "compile" this line and not warn me about it.

Moreover, for the random number generator, setting the seed will also change the internal state and reset the stream of random numbers that you'll get. This is a rather large side effect for a setter, whose effects are typically limited to the property you just set.

---

Non-exported write-only properties should work, except that GDScript will still allow you to read from it and get null back. As you say, that could be papered over by adding an autogenerated getter that simply panics, but it's still a potential source of confusion.

Exported write-only properties:

• Serializing these can never work. The editor needs to read the value in order to serialize it. Otherwise it's going to serialize null and subsequently deserialize null as well, overwriting the value you thought you'd set. (I assume. Needs testing.)
• You could unset PROPERTY_USAGE_STORAGE to expose the property only in the editor, but not serialize it. But then you'd type the value, press Enter, and it would disappear. (I assume. Needs testing.) You wouldn't be able to check that you did it right.

Without a concrete use case that isn't better served by methods, I think it's best not to add this footgun. And in fact I would argue for it to be removed for #[var] as well (breaking change) until a concrete use case arises.