[swift-evolution] [Pitch] Change custom operator rules to reserve operators for future use?

[Austin Zheng]

Hi all,

Would there be any interest in a proposal to tighten the custom operator
naming rules in order to reserve operators for future language features?
This would be a source-breaking change, so it would fit the Swift 3
timeline.

The advantages of doing so:

- Future features benefit from more aesthetic and easier-to-use syntax if
they don't have to work around potential custom operator collisions. There
is a pretty big list of potential features that could benefit from such
syntax: Rust-style ownership/borrow-checking, variadic generics, a future
return of the tuple splat, sugar for boxing value types to give them
identity, etc.

The disadvantages of doing so:

- Developers who want to define custom operators (please distinguish this
from operator overloading, which would not be affected) will have a
slightly narrower space of options to choose from.

I personally don't feel all that broken up about potentially breaking
custom operator code in order to reserve room for future feature
development, especially since custom operators should be used sparingly to
begin with.

If people think this is a good idea, it would also be useful to figure out
exactly what sorts of operators we'd want to reserve for future use, as
part of hammering out a formal proposal.

Thoughts?

Best,
Austin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160629/e4655211/attachment.html>