[vouaobrasil]

Technically, "enable_ai" doesn't imply that all AI features are really turned off. Without context, it might imply that some basic AI features exist and "enable_ai" just enables further features. "disable_ai" is unambiguous.

[whilenot-dev]

Enable/disable are the only two dichotomies in the whole of all possible states regarding this AI feature, so I'll have to bite: What's your "Technically," referring to here?

[vouaobrasil]

First of all, enable/disable is a dichotomy, and is not a set of two dichotomies.

Second, imagine an editor that has AI running in the background, scanning your files. "Enable_AI" could just mean enable the visibility of the feature to actually use the results. On the other hand, it would sound more suspicious if there were some background AI tasks running, even for training purposes, if "disable_AI" were "True" as compared to "Enable_AI" to be false.

In other words, Enable_AI COULD have the connotation (to some) of just enabling the visibility of the feature, whereas Disable_AI gives more of a sense of shutting it off.

Imagine for example you're in a court of law. Which one sounds more damning?

======= Prosecutor: You still have AI tasks running in the background but AI_Enable is set to false?

Defendent: But Enable_AI just means enabling the use of the output! ====

==== Prosecutor: You still have AI tasks running in the background, but AI_Disable is TRUE?

Defendent: Uh.... ====

[bheadmaster]

> Enable_AI COULD have the connotation (to some) of just enabling the visibility of the feature, whereas Disable_AI gives more of a sense of shutting it off.

Personally, I don't feel much difference between the two. I doubt that an average reasonable person would either.

[vouaobrasil]

Well, I do feel a distinct connotational difference, but then again, I could be the only one I suppose. And if the average person doesn't care, then why argue about it at all? And how many average people will be using Zed anyway?

[bheadmaster]

> why argue about it at all

Because double negatives are confusing. Enable_AI = true is much clearer than Disable_AI = false.

[criddell]

I don't buy your argument.

> ==== Prosecutor: You still have AI tasks running in the background, but AI_Disable is TRUE?

Defendent: But Disable_AI just means disabling the use of the output

[vouaobrasil]

Well, I guess we'll see then. Or not.

[whilenot-dev]

======= Prosecutor: You still have AI tasks running in the background but AI_Disable is set to true?

Defendent: But Disable_AI just means disabling the use of the output! ====

==== Prosecutor: You still have AI tasks running in the background, but AI_Enable is FALSE?

Defendent: Uh.... ====

...it cuts both ways, sorry.

[vouaobrasil]

Perhaps. I could be the only one that senses a difference, but for those that hate AI like I do, "disable" sounds better than "enable".

[anttiharju]

My pet peeve is CGO_ENABLED compiler option in Go. It's set to 0 or 1 to enable/disable (can never remember which mapa to which)

If it was just CGO=true or CGO=false I think so much confusion could have been avoided.

I think similar thinking applies here. It's convoluted to disable something by setting ai_disable=true because I read it like: setting false true instead of just setting boolean.

[oreilles]

> It's set to 0 or 1 to enable/disable (can never remember which mapa to which)

That's crazy. Boolean logic is the most fundamental notion of computer science, I can still remember learning that in my very first course on my very first year.

[anttiharju]

I've no issues with boolean logic (&&, ||) but unfortunately all my schooling has done those with the notion of true/false instead of bits iirc.

[scbrg]

This follows a convention that was well established and felt pretty ancient when I learned about environment variables in the nineties (i.e. 30 years ago). Variables that are flags enabling/disabling something use 1 to enable, and 0 to disable. I'd not be surprised if this has been pretty much standard behavior since the seventies.

This is not unique to Go.

[whilenot-dev]

I always thought that an unset boolean env var should define the default behavior for a production environment and any of these set with a value of length>0 will flip it (AUTH_DISABLED, MOCK_ENABLED, etc.). I thought env vars are always considered optional by convention.

[anttiharju]

At least in the case of cgo_enabled it does define the default behaviour

[anttiharju]

I don't doubt any of that but why stick to such old conventions when there are explicit and immediately clear options?

I don't think me writing an if condition

if boolean != true

instead of

if boolean == false

should pass code review. I don't think my pet peeve is necessarily different from that. I understand there's a historical convention but I don't think there's any real reason for having to stick to it.

Hell, some of the other compiler options are flags with no 0 or 1, why could this not have been --static or any flag? I'm genuinely curious.

Moreover, 0 here maps to false but in program exit codes it maps to success which in my mind maps to true but then we have this discrepancy so it does not appear to be the right mental model.