On Sunday, 10 April 2022 at 14:34:41 UTC, Timon Gehr wrote:
> You seem to be contradicting yourself. It's either bad logic or bad communication.
I think it's the latter. I think the chief source of bad communication is actually a design flaw in DIP1035:
https://forum.dlang.org/post/tgbwhgxzkrupdotylkms@forum.dlang.org
@system
variables are not a bad idea. DIP1035's mistake is in thinking that anyone would ever want a @system
variable by accident.
Once you subtract all of the evidence against me which relied on the design flaw in DIP1035, what part of your case still stands?
All of the actual use cases for @system
variables — I mean real @system
variables, not just unsafely initialized ones — that I have seen (some are illustrated in the DIP, but also in Steven Schveighoffer's really excellent presentation on tagged unions) involve preserving the invariant of a data structure by making sure the @system
variable is only modified simultaneously with some other piece of data.
Which means, generally, they are modified along with a normal variable. If the @system
variable had __mutable
characteristics implicitly, the @system
function in which it was modified would also be modifying a non-__mutable
value. Such a function would error anyway.
Maybe there is some other natural use for @system
variables. But none of the use cases I have seen seem particularly incompatible with the additional __mutable
functionality.
> You are basically stating that you will not move away from your position, no matter what.
All I'm doing is trying to make my position clear.
You have to consider everything I've been saying in the context of how @system
variables should have been defined from the beginning — as always explicitly @system
. (I didn't realize just how devastating DIP1035's alternative, "infer @system
everywhere" design really was until I was forced to examine it more closely. I've now made my case about that in the other post.)
This goes for everything I've been saying. Apply the new filter of: "A variable is a @system
variable iff it is explicitly marked @system
."
Me:
> > Again, the only question is whether having __metadata
functionality will cause intractable pain to the use cases of @system
which don't require it.
The solution to our debate — insofar as my claims deserve any merit at all — is to implement both DIP1035 and the __metadata
DIP, with the additional requirement that all uses of __metadata
be marked @system
as well.
I stand by this statement, assuming modified DIP1035.
> In other words, you will just move the goalposts until you can claim you were right.
I honestly don't think that's what I'm doing. My mistake was actually having too strong a sense of the right way to implement @system
variables. I only realized too late that DIP1035 wasn't quite there.
--
I'm sorry for a lot of the stress I've caused. I'm pretty sure that everything I've been saying makes at least a little bit of sense, given what I have always meant (to myself at least ^_^) by "@system
variable".
Zach