[swift-evolution] Operator implementation inside struct/class body
vmartinelli at alecrim.com
Mon Feb 8 15:40:14 CST 2016
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?
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>
> >> 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
> > 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution