<div dir="ltr">Hi all,<div><br></div><div>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.</div><div><br></div><div>The advantages of doing so:</div><div><br></div><div>- Future features benefit from more aesthetic and easier-to-use syntax if they don&#39;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.</div><div><br></div><div>The disadvantages of doing so:</div><div><br></div><div>- 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.</div><div><br></div><div>I personally don&#39;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.</div><div><br></div><div>If people think this is a good idea, it would also be useful to figure out exactly what sorts of operators we&#39;d want to reserve for future use, as part of hammering out a formal proposal.</div><div><br></div><div>Thoughts?</div><div><br></div><div>Best,</div><div>Austin</div><div><br></div></div>