Would var be a simpler replacement for the inout keyword?

[sa-]

It took me a few head scratches to figure out the purpose of inout. Since let variables are immutable and var variables are mutable, it would make the language easier to grasp for a newcomer if the keywords were the same in both occasions

I understand now that inout means that the param is both an input and an output (which is important information if you are the compiler), but maybe this alternative naming would make the language more accessible.

Let me know what you think!

[lattner]

actually no. var means locally mutable, inout means mutations are visible in the caller. @scottamain is working on an improvement to the documentation here. Scott, can you share your thoughts when those go live?

[sa-]

Thanks, sounds good

[nmsmith]

It may be worth considering whether the owned keyword could be unified with var Chris? Since every owned implies being locally mutable, and every var implies ownership.

[lattner]

Yes, I think it might make sense eventually to replace "owned" with var. With lifetimes, we're likely to have local inout declarations, and naming those "inout let" or "inout var" is weird. I'd like to make more progress on lifetimes before painting this. They are next up in terms of big new features, so it won't be long to sort this.

[scottamain]

Yeah, please have a look at the updated docs about argument conventions here:
https://docs.modular.com/mojo/programming-manual.html#argument-passing-control-and-memory-ownership
I hope this is easier to understand now, @sa- . Please share any feedback. Thank you!

[sa-]

That does look pretty clear now, thanks for looking into it :)

[ksandvik]

Less keywords is a good thing, as long as they mean the exact same thing (unlike the C++ mess).

[ego]

Some notes over Argument passing control and memory ownership, def/fn, etc

Rename keyword inout to symbol ! (attention) or more Pythonic global (but visible only in the caller)

struct Int:
    fn __iadd__(!self, rhs: Int):
        self = self + rhs


struct Int:
    fn __iadd__(global self, rhs: Int):
        self = self + rhs

Another way is to describe all these nuances via sime kind of typing system or special type directive

struct Int:
    fn __iadd__(self: InOut, rhs: InOut[Int]):
        self = self + rhs

struct Int:
    fn __iadd__(self: Global, rhs: Global[Int]):
        self = self + rhs

Maybe keep only one keyword for a function

def => def copy_arguments(a: LocalCopy[Int]):
fn => def read_original(a: ImmutableRef[Int]):

borrowed to const or static ...

fn use_something_big(const a: SomethingBig, b: SomethingBig):
    a.print_id()

or like a typing:

fn use_something_big(a: ConstRef[SomethingBig], b: SomethingBig):
    a.print_id()

def use_something_big(a: ConstRef[SomethingBigA], b: ImmutableRef[SomethingBigB], c: LocalCopy[SomethingBigC]):
    a.print_id()

[lattner]

I'm closing this because we're not renaming the inout keyword right now. We will do a full repaint of the new keywords when the language matures.