[swift-evolution] Operator implementation inside struct/class body

[Vanderlei Martinelli]

The initial proposal mentions static members, because I thought it was only
a matter of moving things from one place to other and because I saw
something like this in C#.

After reading your messages, however, I have to agree that the second
approach, using instances members, is a much better one.

About the name lookup algorithm and shadow/override things, I’m afraid I do
not know what to say. What options do we have?


Regards,

-Van




On Mon, Feb 1, 2016 at 6:41 PM, Chris Lattner <clattner at apple.com> wrote:

>
> > On Feb 1, 2016, at 1:47 AM, Haravikk <swift-evolution at haravikk.me>
> wrote:
> >
> >
> >> On 1 Feb 2016, at 04:55, Chris Lattner <clattner at apple.com> wrote:
> >>
> >> We need multiple modules to be able to define instances of an operator,
> we need operators in extensions, and we need retroactive conformance to
> work, as with any other member.
> >
> > Why?
>
> I’m not sure which piece you’re asking about.  I’m just saying that name
> lookup needs to follow an algorithm, and that algorithm needs to be
> specified.
>
> > Like I say, the operator itself is really static, not a method of an
> instance, as it declares what it operates on in its parameters, just as an
> operator does now, the only difference is being able to declare it in
> class/struct for clarity. There’s also no talk of making explicit operator
> declarations such as Foo.==(a, b),
>
> I agree.
>
> > so it seems to me that nothing will actually change functionally from
> the way operators are now.
>
> You need to specify the lookup order, and how to determine whether
> something is a shadow or redefinitions.  The compiler needs to have an
> algorithm to decide this, and this is an important part of the behavior of
> the feature.  As such a proposal should specify how it works.
>
> -Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160208/2e4ac39b/attachment.html>