[swift-evolution] [Review] SE-0077 v2: Improved operator declarations

[Joe Groff]

> On Jul 7, 2016, at 11:53 AM, Anton Zhilin via swift-evolution <swift-evolution at swift.org> wrote:
> 
> An important thing to consider is if we really want to break standard library precedence hierarchy.
> If we don't, then the proposal loses significance immediately.
> If we do, then we should start discussion of specific changes right after this one.

I think we'll need to anticipate a migration story for this regardless, since we're already constrained on remaining time for breaking changes to Swift 3. If push comes to shove, we could plausibly stage this in after 3.0 by mapping our existing numeric precedences to the corresponding named precedence groups in order to provide compatibility between the two models. We can also deprecate unwanted precedence relationships in the standard library so that they raise warnings before removing them after the compatibility window expires.

-Joe

> I'm fine with NilCoalescingPrecedence, because Coalescing is a noun in this case. For example, we talk about "nil coalescing" operator.
> 
> Situation with namespacing is more intricate. I don't mind Precedence suffixes very much (better make keywords shorter), but it would be great if we came up with an elegant solution for dropping them.
> One idea: add Precedence suffix automatically: 'precedence Additive', 'before: Additive', BUT 'Swift.AdditivePrecedence'.
> 
> 2016-07-07 19:28 GMT+03:00 Dmitri Gribenko via swift-evolution <swift-evolution at swift.org>:
> On Thu, Jul 7, 2016 at 9:27 AM, John McCall <rjmccall at apple.com> wrote:
> > On Jul 7, 2016, at 9:23 AM, Dmitri Gribenko via swift-evolution
> > <swift-evolution at swift.org> wrote:
> >> Proposal link:
> >>
> >> https://github.com/apple/swift-evolution/blob/master/proposals/0077-operator-precedence.md
> >
> > Dave, Max and I discussed SE-0077 and reviewed the names of precedence
> > groups.
> > Here's our recommendation.
> >
> > In general, we think some names don't read well and have some ambiguities,
> > for
> > example, "LogicalAndPrecedence" (looks like a conjunction),
> > "AdditivePrecedence" ("additive" is an adjective that modifies
> > "precedence"),
> > "RangePrecedence" ("range" is not an adjective, stands out).
> >
> > We think that two directions would be fruitful:
> >
> > 1.  If the names of precedence groups will be in the same namespace as
> > types,
> >     then we recommend pushing the names of precedence groups into a
> > "namespace",
> >     for example "Precedence.Assignment".
> >
> > We don't have any language features that would allow this.
> 
> 'precedencegroup' that is being proposed is a new language feature, we
> can choose to use any syntax we like with it.
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution