setfield! does not call convert

[stevengj]

type Foo; x::Float64; end
foo = Foo(0)
foo.x = 3
foo.(:x) = 4
setfield!(foo, :x, 5)

The last line throws TypeError: setfield!: expected Float64, got Int64.

[yuyichao]

This is expected since convert is inserted by the parser. Calling convert in the actual builtin sounds much more complicated (it needs to find the right one for example).

[stevengj]

Since the foo.(:x) syntax may be going away (#6268 and/or #15032), it seems desirable to beef up setfield! a bit so that it is more usable.

[stevengj]

The relevant code is in builtins.c. Since it knows the type that it wants at that point, it doesn't seem too hard to insert a call to Base.convert.

[vtjnash]

We can change it so that Base exports:

setfield!(x, i, v) = Core.setfield!(x, i, convert(fieldtype(x, i), v))

Otherwise, it's pretty hard to insert a call to convert directly from an Intrinsic, since Core.Intrinsics.convert is probably not what you ever intended to call (it's undefined) :P

[tkf]

This issue seems to be not resolved yet. I can reproduce the issue in Julia 1.0, 1.1, and 1.2-DEV.

   _       _ _(_)_     |  Documentation: https://docs.julialang.org
  (_)     | (_) (_)    |
   _ _   _| |_  __ _   |  Type "?" for help, "]?" for Pkg help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 1.0.3 (2018-12-18)
 _/ |\__'_|_|_|\__'_|  |  Official https://julialang.org/ release
|__/                   |

julia> mutable struct Foo x::Float64; end

julia> foo = Foo(0)
Foo(0.0)

julia> foo.x = 3
3

julia> setfield!(foo, :x, 5)
ERROR: TypeError: in setfield!, expected Float64, got Int64
Stacktrace:
 [1] top-level scope at none:0

cc @stevengj

ref JuliaPy/PyCall.jl#675

[yuyichao]

julia> mutable struct Foo x::Float64; end

julia> foo = Foo(0)
Foo(0.0)

julia> foo.x = 3
3

julia> setproperty!(foo, :x, 5)
5.0

setfield! is the wrong function to call.

[tkf]

setfield! is the right function to call if you override setproperty!. This is the case in JuliaPy/PyCall.jl#675. I think it is useful to have a uniform behavior for set-field operation. At least, I think the difference is better be documented to close this issue.

[yuyichao]

No, for a start, this was an issue because setfield! was documented as the lowering of a.b = c which is not the case. The solution is simple, creating a documented function that exactly corresponds to a.b = c and that's setproperty!. Having setfield! (i.e. the exact spelling) doing extra work was never the intent of the issue.

I think it is useful to have a uniform behavior for set-field operation

There isn't any non-uniform behavior of set-field operation. The dot syntax is always lowered to setproperty! which I believe is documented well.

setfield! is the right function to call if you override setproperty!

It is the right function to use only if its behavior is what you want. If, however, what you want is the behavior of the default setproperty! implementation, then you should call that instead. The generic way to do that is invoke, no different from any other overloadable functions.

[yuyichao]

I think the difference is better be documented

Also, please actually check the document of setfield!. It explicitly says,

The value must be mutable and x must be a subtype of fieldtype(typeof(value), name).

and also crossed linked to setproperty!.

Improving the doc is certainly always welcome but AFAICT there isn't anything missing for this issue so there's no need to keep an issue open for potential generic doc improvement.

[tkf]

Sorry, I have no idea why I missed that part. Thanks for the clarification.