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

[Tony Allevato]

Hi Dmitri, thanks for the great feedback. I've updated the pull request <
https://github.com/apple/swift-evolution/pull/283>.


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.
>

Done.


> 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
operators.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160503/6e84a5c4/attachment.html>