fix language inconsistency for mutating methods

[human154]

Currently mutation is explicit for function calls but not method calls:

sort(mut mutable_item)
// here the current syntax makes mutation explicit

mutable_item.sort()
// here the current syntax allows silent mutation
// for the same functionality

Since the extremely minimal syntax of appending an exclamation mark, as in mutable_item.sort!(), has apparently already been rejected by the community....

Here I'm suggesting:

mutable_item!sort()
// the new syntax would use an exclamation mark
// in place of the dot operator for mutating method calls

I'm not sure how we can cut down the typing much more than that.
Replacing the dot with ! means one less keypress than sort!() and it has an added advantage: with autocompletion it can trigger a filtering of suggestions to include only mutating methods. Finally, this way methods don't need a special name.

That would mean there may actually be no net extra typing.

Another option could be capitalizing:

mutable_item.Sort()
// Same benefits as ! but actually also enhances the readability, I think

If this change makes it in, I'm imagining that at first the compiler would just give a warning when the new syntax is expected.

[dumblob]

Is it already decided that if by accident panic() will stay in V, that ! will not be used as syntactic sugar for or { panic( err ) } (i.e. instead of returns_optional() or { panic( err ) } one would write returns_optional() !)? Note also interesting cases like returns_optional() ! ! in [1, 2, 3].

[mcastorina]

I'm still new to the community.. why is sort!() syntax off the table? I quite like it because it indicates a mutating method (as you stated). Also, I wouldn't want ! to make using panic easier.

Why not allow ! character in method names but still require using mut.

fn (mut item Item) sort!() { } // proper usage
fn (item Item) sort!()         // warning (no mut)
fn (mut item Item) sort()      // warning (no !)

[dumblob]

why is sort!() syntax off the table?

I don't think it's off the table. But I was just asking about potential conflicts depending on other decisions (I'm not following V's development due to lack of time, but I know there are other syntax-related ongoing discussions).

[ntrel]

with autocompletion it can trigger a filtering of suggestions to include only mutating methods

That sounds useful. Plus if I expect a method with mutable receiver that actually returns a copy of the receiver without mutation, then I would get an error:

fn (r R) meth() R
...
mut rec = R{}
rec!meth() // error, `meth` does not mutate receiver`

Currently that would be a silent bug.

fn (mut item Item) sort!() { } // proper usage

That seems like unnecessary complexity.

about potential conflicts

We do have [e1, e2]! for a fixed array literal. It wouldn't be a conflict, but it would be unfortunate overloading of a token that would then have 3 different meanings. Personally I would fix that by changing the fixed array literal syntax (it was anyway only recently changed from !!).

[dumblob]

We do have [e1, e2]! for a fixed array literal.

What does this use of ! mean? I can't find it in the doc (nor the former syntax !!).

[ntrel]

I can't find it in the doc

It's not documented. It means a fixed-size array literal.

[galman33]

What about

mut mutable_item.sort()

?