Is it expected behaviour that i can assign an int to my struct

[rd4com]

That is cool, but is expected behaviour?

import sys.intrinsics
fn type_eq[T:AnyType,T2:AnyType]()->Bool:
    return intrinsics._mlirtype_is_eq[T,T2]()
@value                        #if remove this you cannot x to custom
struct my_struct:
    var x:Int
    fn __init__(inout self:Self):
        self.x=0

fn main():
    print(type_eq[Int,my_struct]()) #True
    var custom:my_struct = my_struct()
    var x:Int = 0
    custom = x        #ok
    x=custom          #not ok

[ivellapillil]

I think it is a bug in the type system. Hard to believe that it is an intentional feature, as it would make the type system unreliable.

[Mogball]

This is intentional. Putting @value on my_struct adds a definition for

struct my_struct:
  fn __init__(inout self, x: Int):
    self.x = x

Which enables implicit conversion from Int to my_struct. The statement custom = x is invoking the implicit conversion.

[lattner]

Yep that's what happens. I think it is super debatable whether that is a good thing though :-). Mojo doesn't have the notion of "explicit" constructors - I think we should require custom = my_struct(x) but we don't have a way to express that yet.

[ivellapillil]

I would prefer that conversations be explicit. Implicit conversations are very confusing in large code base, especially when we introduce custom types that does not have an is-a/extends relationship....

[lattner]

yes, agreed. We need to figure out what our approach to "explicit" ctors are and what the default should be for @value. I tend to agree that implicit ctors should be opt-in, but we need to discuss it.