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

[Anton Zhilin]

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'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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160707/54b9b85f/attachment.html>