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