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

[Jonathan Hull]

I don’t like the idea (which I have seen in several different pitches recently) of breaking things now so that some theoretical future feature might be possible.  Much better, I think, to wait until we have a concrete proposal and than break things then if necessary.  Otherwise we will just leave a trail of half-broken things in the wake of features which never quite happen (or which happen in a different form than we originally thought).

I do realize that Swift 3 is being thought of as the “Last chance to break things” on a massive scale, but that doesn’t mean that we should break things for breaking’s sake.  I am sure there will be a few small breaking changes with every release, and I would put this sort of thing in that category.  The things which NEED to happen this release are things like the grand renaming, the new collection model, and shuffling around the standard library… because those will affect everyone’s code.

This will affect a much smaller subset.  It will probably break one of my frameworks (which is used in 3 different projects), but it will not break the majority of my work.  The grand renaming will affect every single project I have… and those types of changes are the ones we need to avoid post Swift 3…

Thanks,
Jon

> 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/20160630/3b8ee154/attachment.html>