I am not sure if that should work.

@medvednikov what do you think?

Looking into it again. It should not work at that point. has_arg is always false at the point of the condition and it would not guard when args are passed as not mutable.

So, if a mutable params struct should be allowed after all, the second example below should trigger an error that the arg would have to be passed as part of a mutable struct.

foo() // should work with a mutable params struct?

foo(a: true) // with the PR it doesn't error if the args param is mutable

mut p := Params{a: true} // Should required when deciding o pass a mutable params struct?
foo(mut p)

@spytheman I agree, I think mutable params simply shouldn't be allowed.

Okay, I updated the PR to disallow it when declaring a fn with it.

But I don't fully see through where it would cause problems. Why not allowing it to be handled like any other mutable struct and to be optional?

Okay, I updated the PR to disallow it when declaring a fn with it.

But I don't fully see through where it would cause problems. Why not allowing it to be handled like any other mutable struct and to be optional?

For normal non @[params] mut arguments, you have to use mut in all call sites, i.e. do f(mut s). You can not just f(Struct{}) or f(s).

If you allow f() or f(some_field: some_value) for fn f(mut opts Params) {, then you would not have to use mut inside the calls - they will look just like normal calls, that do not pass any mutable state down to f().

That can be valuable, but also inconsistent.

-> I can see it both ways, thus I could not decide how it should behave.