Proposing AND, OR as alternative syntax for the &&, || logical operators?

gregh · September 18, 2026, 9:32pm

I performed a cursory search of past Swift proposals, and I did not find any that proposed that Swift recognize and and or as alternative tokens for the current logical && and || operators. So, I am posting here to try and find out for certain whether this Swift language enhancement has in fact ever been proposed (and, presumably, rejected).

The purpose of this enhancement would be to provide Swift with a more human-readable, "script-like" syntax - which I believe aligns well with Swift's longstanding goals as a language. This addition would also make Swift syntax more consistent with other programming languages (including C++, which supports both syntaxes) - and thereby better accommodate new Swift programmers (who may have experience in other languages, such as Python) and help make them feel more at home in Swift.

I am more interested in confirming that this would be a novel proposal, rather than discussing its merits at this point in its evolution. Although I am not opposed to having such a discussion in an appropriate forum.

Greg

JohnBlackburne · September 19, 2026, 12:19am

github.com/swiftlang/swift-evolution

commonly_proposed.md

main

# Commonly Rejected Changes 

This is a list of changes to the Swift language that are frequently proposed but that are unlikely to be accepted.  If you're interested in pursuing something in this space, please familiarize yourself with the discussions that we have already had.  In order to bring one of these topics up, you'll be expected to add new information to the discussion, not just to say, "I really want this" or "this exists in some other language and I liked it there".

Additionally, proposals for out-of-scope changes will not be scheduled for review. The [readme file](README.md) identifies a list of priorities for the next major release of Swift, and the [dashboard](https://www.swift.org/swift-evolution/) includes a list of changes that have been rejected after a formal review.

Several of the discussions below refer to "C family" languages. This is intended to mean the extended family of languages that resemble C at a syntactic level, such as C++, C#, Objective-C, Java, and JavaScript. Swift embraces its C heritage. Where it deviates from other languages in the family, it does so because the feature was thought actively harmful (such as the pre/post-increment `++`) or to reduce needless clutter (such as `;` or parentheses in `if` statements).

## Basic Syntax and Operators

 * [Replace `{}` brace syntax with Python-style indentation](https://forums.swift.org/t/brace-syntax/678/3): Surely a polarizing issue, but Swift will not change to use indentation for scoping instead of curly braces.

 * [Remove `;` semicolons](https://forums.swift.org/t/proposal-to-remove-semicolons/523/3): Semicolons within a line are an intentional expressivity feature.  Semicolons at the end of the line should be handled by a linter, not by the compiler.

 * [Replace logical operators (`&&`, `||`, `!`, etc.) with words like "and", "or", "not"](https://forums.swift.org/t/change-the-name-of-the-boolean-operators/30/2), and [allow non-punctuation operators](https://forums.swift.org/t/allowing-characters-for-use-as-custom-operators/952) and infix functions: The operator and identifier grammars are intentionally partitioned in Swift, which is a key part of how user-defined overloaded operators are supported.  Requiring the compiler to see the "operator" declaration to know how to parse a file would break the ability to be able to parse a Swift file without parsing all of its imports.  This has a major negative effect on tooling support. While not needing infix support, `not` would need operator or keyword status to omit the parentheses as `!` can, and `not somePredicate()` visually binds too loosely compared to `!somePredicate()`.

 * [Replace `?:` ternary operator](https://forums.swift.org/t/ternary-operator-suggestion/49/148): Definitely magical, but it serves a very important use-case for terse selection of different values.  Proposals for alternatives have been intensely discussed, but none have been "better enough" for it to make sense to diverge from the precedent established by the C family of languages.

## Strings, Characters, and Collection Types

This file has been truncated. show original

tera · September 20, 2026, 8:32pm

No, that would be a too major change. Currently, the sets of characters that can be used in operators and identifiers do not overlap.

The obvious alternatives

you custom standalone functions, example:

    not(and(or(a, b), or(c, d)))

ditto but methods on Bool, for example:

    a.or(b).and(c.or(d)).not

Those would be equivalents of:

    !((a || b) && (c || d))