[swift-evolution] [Proposal] Improving operator requirements in protocols
allevato at google.com
Tue May 3 13:41:19 CDT 2016
Hi Dmitri, thanks for the great feedback. I've updated the pull request <
On Mon, May 2, 2016 at 5:53 PM Dmitri Gribenko <gribozavr at gmail.com> wrote:
> On Mon, May 2, 2016 at 9:44 AM, Tony Allevato via swift-evolution
> <swift-evolution at swift.org> wrote:
> > I've written a proposal to formalize some of the discussion that was had
> > over in the thread for the `FloatingPoint` protocol proposal regarding
> > improvements to operator requirements in protocols that do not require
> > methods be added to the protocol and conforming types. Thanks to everyone
> > who was participating in that discussion!
> > The proposal can be viewed in this pull request and is pasted below.
> Hi Tony,
> I'd like to post this feedback on behalf of Dave Abrahams, Maxim
> Moiseev and myself.
> We are in favor of your proposal, but we would like to request a few
> 1. Could you remove the section about the stretch goal to generate
> the trampolines automatically? We think that the proposal provides
> enough value by itself, and we generating the trampolines will just
> complicate the implementation, delaying the user model improvement.
> This can come later.
Done. I left a brief mention (once sentence) of it in "Alternatives
Considered" so that the history of it wasn't completely lost.
2. The section about the classes is written in a way that seems to
> imply that the proposal regresses the way Equatable works with
> classes. We don't think this is the case. Could you change to just
> acknowledge the problem and say that we are not fixing it in this
Done—I removed all of the code examples and tightened it up into a brief
discussion acknowledging the issue.
3. Could you explain in more detail how the name lookup works in the
> proposal? In particular, it would be good to emphasize that regular
> name lookup done when type checking an infix expression would not find
> an operator defined as a type member.
> 4. What do you think about adding a rule to disallow defining member
> operators that don't satisfy a protocol requirement?
Added. That seems like a reasonable and appropriate requirement, since the
feature is being proposed specifically to improve protocol-required
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution