Brendan Hansknecht (Sep 11 2024 at 20:04): Brendan Hansknecht (Sep 11 2024 at 20:04):#ideas>`not` keyword instead of `!` prefix discussion has come to the conclusion that it should stay the same for now. Thought I would just ask:
Are we open to the idea of just changing && and || to and and or?
I think it is mostly this way in python and zig, but probably other languages as well. Given we don't have the binary equivalents (& and |), having && and || feels silly to me. I think we should change these to keywords.
I think it would be reasonable to change theses without changing ! to not.
Kevin Gillette (Sep 11 2024 at 20:32):What would this look like in practice?
isPublicRoute route or isAuthenticated session and isAuthorized session route
Is that sufficiently clear with syntax highlighting? Is it sufficiently clear without highlighting?
Brendan Hansknecht (Sep 11 2024 at 21:10):Yeah, definitely worse without syntax highlighting. Also, I personally always use parens when mixing and and or.
Let's see if python syntax highlighting can help....
if isPublicRoute route or (isAuthenticated session and isAuthorized session route) then
Austral lang has no operator precedence to force users to put parentheses for disambiguation. Might be a good idea for and and or
Kevin Gillette (Sep 12 2024 at 06:10):Per that point, just because of the argument spacing style, I'd probably put parens around any function call that is used in a larger boolean expression, or alternatively, hoist the calls into assignments so that the boolean expression consists only of non-call expressions.
Tobias Steckenborn (Sep 12 2024 at 09:26):I anyways find the space separation tough to read without syntax highlighting 🤷🏼♂️
Andrea Bueide (Sep 12 2024 at 23:15):i think we should value consistency and familiarity here. and/or/not are probably better for people who are newer to programming, but I think ! && || are better in terms style and familiarity, but I definitely do not think we should mix and match the two paradigms otherwise you're getting the downsides of both
Sam Mohr (Sep 12 2024 at 23:17):Python is at least in the top 3 languages in the world, and it uses and and or. I think it's fair to say that their version of things is very familiar with newcomers, if not more familiar than && and ||.
Sam Mohr (Sep 12 2024 at 23:17):The mixing and matching is my main worry, though
Brendan Hansknecht (Sep 13 2024 at 03:37):Yeah I agree with both of those statements. That's why I'm pro and and or despite being much more used to && and ||.
Richard Feldman (Sep 13 2024 at 20:06):we currently have no named keywords that are infix, and lots of infix operators
Richard Feldman (Sep 13 2024 at 20:06):so it feels like the bar for introducing an inconsistency there should be pretty significant haha
Brendan Hansknecht (Sep 13 2024 at 20:16):That's a fair point
Joshua Warner (Sep 14 2024 at 17:50):Food for thought: what if the parser accepted both but the formatter produced one? That might ease the transition for users coming from languages where one or the other of those is the norm. And that's pretty easy to do in the parser. When implemented properly it should have little to no perf impact on parsing.
Brendan Hansknecht (Sep 14 2024 at 17:52):I think that only works if and and or are the wanted output. Or are keywords despite && and || being the canonical forms. I don't think we could generically convert and and or to && and || otherwise.
Joshua Warner (Sep 14 2024 at 18:02):Agreed
Matthieu Pizenberg (Sep 15 2024 at 09:28):I like and and or personally, but don’t mind the current thing.
Last updated: Jun 16 2026 at 16:19 UTC