Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No ambiguity error on field overloaded by `field=` #11514

Closed
dom96 opened this issue Jun 16, 2019 · 5 comments

Comments

@dom96
Copy link
Member

commented Jun 16, 2019

type
  FooBar = object
    foo: string
 
proc `foo=`*(f: var FooBar, v: string) =
  echo("This isn't executed...")
  f.foo = v

var x = FooBar()
x.foo = "hello"

I expect to get an error in this case. Not it silently assuming I want to assign the field (but not via the proc I created). The same thing happens if FooBar is in another module and foo field is exported (which I how I ran into this)

@Araq

This comment has been minimized.

Copy link
Member

commented Jun 17, 2019

It works according to the spec but the spec needs to be more explicit about this: obj.field is interpreted as obj.field unless it cannot be interpreted this way, then accessors are considered. Usually this rule produces good results, we cannot error with an ambiguity here, that would break far too much code.

@dom96

This comment has been minimized.

Copy link
Member Author

commented Jun 17, 2019

Usually this rule produces good results, we cannot error with an ambiguity here, that would break far too much code.

I find that surprising, is there really that much code which depends on this? If so then the semantics are quite confusing, do you have examples of code that does this?

@Araq

This comment has been minimized.

Copy link
Member

commented Jun 17, 2019

How about we start with the insight that

proc `foo=`*(f: var FooBar, v: string) =
  echo("This isn't executed...")
  f.foo = v

itself only works with this rule? Otherwise it would be an infinite recursion...

@bluenote10

This comment has been minimized.

Copy link
Contributor

commented Jun 17, 2019

There could be solutions to this, right?

  • Explicit: f.foo {.field.} = v
  • Implicit: Within foo=, f.foo is treated as field access.

Despite being a fairly big break, I'd love to see a solution to this.

Example that suffers from the behavior: nim-finals which only works across modules, not within modules 😕

Would it be possible to use the "important packages test suite" to estimate the percentage of affected packages?

@Araq

This comment has been minimized.

Copy link
Member

commented Jun 27, 2019

Would it be possible to use the "important packages test suite" to estimate the percentage of affected packages?

Only after we implemented the required changes.

@Araq Araq closed this in d9604d7 Jun 27, 2019

narimiran added a commit that referenced this issue Jul 2, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.