[Pitch] Precedence Presets

Throwing this out there for some quick opinions. – E

Adding “Human”-consumable Precedence Group Presets

  • Proposal: SE-00xx
  • Authors: Erica Sadun
  • Review Manager: TBD
  • Status: TBD
  • Decision notes: TBD
  • Implementation: TBD
  • Write-ups and Discussion threads: TBD
  • Review thread: TBD

Introduction

This proposal introduces preset precedent groups for utility work.

Motivation

Operators should be used rarely and thoughtfully. Many custom operators are used in lightweight scripting to simplify exploration in playgrounds (such as debugging or casting operators) or as in-house utilities. Of these, many don’t use explicit precedence at all. When they do, it’s unwieldly to have to start going through Swift source to discover exactly where your operator group should fall:

BitwiseShiftPrecedence > 
MultiplicationPrecedence > 
AdditionPrecedence > 
RangeFormationPrecedence > 
CastingPrecedence > 
NilCoalescingPrecedence > 
ComparisonPrecedence > 
LogicalConjunctionPrecedence > 
LogicalDisjunctionPrecedence > 
TernaryPrecedence > 
AssignmentPrecedence > 
FunctionArrowPrecedence > [nothing]

It’s useful to provide a limited established set of human-centric precedence, easy to remember, easy to use groups that avoid diving into Swift’s more nuanced collection.

Proposed solution

Add super-simple, obvious groups for those times you just want to throw together an operator and need precedence:

/// Human-centered low precedence group
precedencegroup LowPrecedence { higherThan: VeryLowPrecedence }

/// Human-centered very low precedence group
precedencegroup VeryLowPrecedence { lowerThan: FunctionArrowPrecedence }

/// Human-centered very high precedence
precedencegroup VeryHighPrecedence { higherThan:  HighPrecedence}

/// Human-centered high precedence
precedencegroup HighPrecedence { higherThan: BitwiseShiftPrecedence }

/// Human-centered left associative precedence
precedencegroup LeftAssociativePrecedence { associativity: left }

Source compatibility

This proposal is strictly additive.

Effect on ABI stability

This proposal does not affect ABI stability.

Effect on API resilience

This proposal does not affect ABI resilience.

Alternatives considered

Nope

I totally get the motivation for this, but I think I’m overall a -1 on this issue.

Precedence isn’t an easy thing to get right. I’ve spent a lot of time tweaking the precedence stuff in DDMathParser, and it still has subtle flaws in it. Having a general “high/medium/low” grouping sounds nice and easy, but:

  1. It’s semantically wrong; operators have precedence relative to other operators
  2. It encourages developers to add custom operators (“look defining precedence is easy!”), which tends to obfuscate code
8 Likes

I agree with @davedelong. Precedence groups are an advanced feature, and deservedly so, because there are subtleties to their correct operation. The existing groups are carefully designed with semantics that are very clear. “Very low precedence” has no semantics and is inconsistent with that design.

It would be my view that the Swift standard library should not have support for (or even discourage) “those times you just want to throw together an operator and need precedence.” If desired, these can be vended as a custom library.

1 Like

I think this is a tooling problem, not a language problem.

In Xcode 9.2, when I type,

infix operator &&&&& :

I do not get autocomplete recommendations for existing precedencegroups.

Similarly, if I type,

precedencegroup MyPrecedence {

I do not get stubs for any of “higherThan”, “lowerThan”, “associativity”, nor “assignment”. In fact when I start typing those terms, none of them autocomplete, and when I put a colon after them I do not get recommendations for valid values.

I am not sure of the relationship between the Swift language and Xcode’s autocomplete, but I think that is where improvements are warranted.

11 Likes