[swift-evolution] [Proposal] Improving operator requirements in protocols

Tony Allevato 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
> named
> > 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
> modifications.
> 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
> proposal?

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...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160503/6e84a5c4/attachment.html>

More information about the swift-evolution mailing list