Why assignment operators return the right-hand-side

[Benny]

@Mason

do you really read that as

temp = (;a=1, b=2, c=3, d=4)
(;a, b) = temp
x = temp

Yes, out of habit (Python). I think it’s better this way: even if we don’t let assignment convert, indexing and properties may do more drastic changes, so x = y[1] = 0 resulting in y[1] = 0; x = 0 is much more predictable than y[1] = 0; x = y[1] # may not be 0. It could have easily gone the other way, I think C does that.

@sadish-d

My point was just that a Base.convert method needs to be defined for user-defined types, which disadvantages them over primitive types. This was a counterargument that conversion of Char to Int is not the (only) thing that’s weird to me about ::, but that a convert is called to begin with.

Oh I see. As I mentioned before, primitive types are a bit special because they aren’t composed of anything. The conversion-constructor equivalence isn’t automatic either, for example there are convert methods among Number and AbstractChar that forward to the type constructor and then assert the type:

# number.jl
convert(::Type{T}, x::T)      where {T<:Number} = x
convert(::Type{T}, x::Number) where {T<:Number} = T(x)::T
# char.jl
convert(::Type{AbstractChar}, x::Number) = Char(x) # default to Char
convert(::Type{T}, x::Number) where {T<:AbstractChar} = T(x)::T
convert(::Type{T}, x::AbstractChar) where {T<:Number} = T(x)::T
convert(::Type{T}, c::AbstractChar) where {T<:AbstractChar} = T(c)::T
convert(::Type{T}, c::T) where {T<:AbstractChar} = c