On Mon, May 2, 2016 at 9:44 AM, Tony Allevato via swift-evolution
<swift-evolution@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.
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?
You wrote to Dave:
> We do have some problems today, such as above where using `==` on a `(Base,
> Subclass as Base)` pair ends up calling `==(Base, Base)` because we lack
> multiple dispatch. What surprised me though was that the `eq` call between
> two `Subclass` instances passed to the trampoline operator ended up calling
> `Base.eq`. I would have expected `Subclass.eq` to be called there since the
> generic argument `T` was bound to `Subclass`. Today, a non-generic
> `==(Subclass, Subclass)` operator *does* do the right thing.
The reason why the trampoline calls the ==(Base,Base) overload in
Subclass is because it is a part of the override chain for the base
class method that introduces the conformance.
The reason why the non-generic ==(Subclass,Subclass) operator does the
right thing is because it is a better match for overload resolution of
== at the callsite. But if you have a (Subclass as Base, Subclass as
Base) pair, even today it will call ==(Base,Base).
Therefore, we think that this section describes the exact problem that
we have today.
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?
Dmitri
--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <griboz...@gmail.com>*/
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
