- Proposal: SE-NNNN
- Authors: Anton Zhilin
- Review Manager: TBD
- Status: Awaiting review
Bitwise and arithmetic operators are very different, and their precedence relationship is not obvious. This proposal removes this relationship. Expressions with bitwise and arithmetic operators next to each other will need disambiguating parentheses:
a + b | c // was (a + b) | c, now error
a | b + c // was (a | b) + c, now error
a & b * c // was (a & b) * c, now error
a << b + c // was (a << b) + c, now errorSwift-evolution thread: Discussion thread topic for that proposal
Currently, operators +, - and | have the same precedence (AdditionPrecedence),
and * and & are both in (MultiplicationPrecedence).
The reasoning behind these relationships is that bitwise OR is mudulo-2 addition,
and bitwise AND is modulo-2 multiplication.
On the other hand, one can argue that these facts are usually not kept in mind when using these operators.
Describe your solution to the problem. Provide examples and describe how they work. Show how your solution is better than current workarounds: is it cleaner, safer, or more efficient?
Describe the design of the solution in detail. If it involves new syntax in the language, show the additions and changes to the Swift grammar. If it's a new API, show the full API and its documentation comments detailing what it does. The detail in this section should be sufficient for someone who is not one of the authors to be able to reasonably implement the feature.
Relative to the Swift 3 evolution process, the source compatibility requirements for Swift 4 are much more stringent: we should only break source compatibility if the Swift 3 constructs were actively harmful in some way, the volume of affected Swift 3 code is relatively small, and we can provide source compatibility (in Swift 3 compatibility mode) and migration.
Will existing correct Swift 3 or Swift 4 applications stop compiling due to this change? Will applications still compile but produce different behavior than they used to? If "yes" to either of these, is it possible for the Swift 4 compiler to accept the old syntax in its Swift 3 compatibility mode? Is it possible to automatically migrate from the old syntax to the new syntax? Can Swift applications be written in a common subset that works both with Swift 3 and Swift 4 to aid in migration?
Does the proposal change the ABI of existing language features? The
ABI comprises all aspects of the code generation model and interaction
with the Swift runtime, including such things as calling conventions,
the layout of data types, and the behavior of dynamic features in the
language (reflection, dynamic dispatch, dynamic casting via as?,
etc.). Purely syntactic changes rarely change existing ABI. Additive
features may extend the ABI but, unless they extend some fundamental
runtime behavior (such as the aforementioned dynamic features), they
won't change the existing ABI.
Features that don't change the existing ABI are considered out of scope for Swift 4 stage 1. However, additive features that would reshape the standard library in a way that changes its ABI, such as where clauses for associated types, can be in scope. If this proposal could be used to improve the standard library in ways that would affect its ABI, describe them here.
API resilience describes the changes one can make to a public API without breaking its ABI. Does this proposal introduce features that would become part of a public API? If so, what kinds of changes can be made without breaking ABI? Can this feature be added/removed without breaking ABI? For more information about the resilience model, see the library evolution document in the Swift repository.
Describe alternative approaches to addressing the same problem, and why you chose this approach instead.