Mutation through let binding (and no &)?

[dholmin]

Hi all,

I just started out playing with the compiler (on MacOS), and one of the first things I typed that I didn't expect to compile, did. Here is the code:

type Thing : Deinitializable {
  public let position: Int
  public let speed: Int
  public memberwise init
}

fun update_physics(_ t: Thing)
{
  t.position += t.speed
}

public fun main()
{
  let t = Thing(position: 0, speed: 1)
  update_physics(t)
  update_physics(t)
  print(t.position)
}

This compiles and prints 2. I was expecting it to complain about mutation through a let binding and missing &s and maybe other things. What am I missing here?

[dabrahams]

Nothing; it's a bug!

[dholmin]

Glad I haven’t misunderstood everything. :) Maybe I should experiment with Ints instead.

[dabrahams]

If Ints are different, that's a bug too

[dholmin]

What do you mean? Using Ints the compiler enforces more rules, but that should be more correct, right? This is a version that uses an Int instead of a struct:

fun update_physics(_ thing: Int)
{
  thing += 1
}

public fun main()
{
  let t = 0 
  update_physics(t)
  update_physics(t)
  print(t)
}

Compiling gives me this:

main.hylo:3.3-8: error: illegal mutable access
  thing += 1

After correcting that and a few more things, I ended up with this, which compiles and runs:

fun update_physics(_ thing: inout Int)
{
  thing += 1
}

public fun main()
{
  var t = 0 
  update_physics(&t)
  update_physics(&t)
  print(t)
}

It's more in line with what I would expect, but is it correct that the inout thing can be mutated without prefixing it with &?

[dabrahams]

What I mean is: an Int is a type defined in the standard library; it is not substantially different from Thing. If it acts differently, that's a bug. That said, obviously, Int has are no stored properties accessible to user code, so you can't test exactly the same things (unless you pass --import-builtin, presumably)

[dholmin]

I see. Thanks.