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.
90% of the list is bikeshedding over syntax right now. The idea that it might be 'distracting' is wholly unconvincing to me, especially because the list participants know exactly what bikeshedding is and eagerly engage in it anyways. A proposal to carve out operators is the least of our worries.
Perhaps I should have said speculative bike shedding. My point is that the core team is extremely busy getting Swift 3 out the door right now and would have to be involved in any discussion about what operators we might wish to reserve. Now is probably not the right time for them to devote attention to something like that.
···
Sent from my iPad
On Jun 29, 2016, at 9:54 PM, Austin Zheng <austinzheng@gmail.com> wrote:
That being said, there doesn't appear to be interest from anyone else, and I'm not interested in putting together a proposal without actual input.
On Wed, Jun 29, 2016 at 7:03 PM, Matthew Johnson <matthew@anandabits.com> wrote:
On Jun 29, 2016, at 3:28 PM, Austin Zheng <austinzheng@gmail.com> wrote:
In the simplest form, we pick out potential operators that we might want to use for future language features, and change the grammar to make them invalid as user-defined custom operators.
Of course the problem with this is picking out the operators! That’s a bike shedding exercise that I fear would prove distracting and not achieve anything close to consensus. The usual difficulties of bike shedding would be exacerbated by the fact that this exercise would be speculative and it would be about operators.
I think the motivation here has merit but I don’t know that there is a good way to do it.
If we don’t do this and then decide in the future that we want to take an operator for the language how much consideration would we give to existing code that is using it as a custom operator? Would this be considered significant enough to prevent us from taking the preferred operator? If not, it probably isn’t worth devoting time to this right now...
On Wed, Jun 29, 2016 at 1:25 PM, Matthew Johnson <matthew@anandabits.com> wrote:
Sent from my iPad
> On Jun 29, 2016, at 3:18 PM, Austin Zheng via swift-evolution <swift-evolution@swift.org> wrote:
>
> 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.
Can you provide more clarity about what you have in mind? It might be useful to consider something along these lines but the details are pretty important.
>
> 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
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution