Rephrase the basic words in Mojo to become as follows

[mojo-for-ai]

I read Chris Lattner's suggestion regarding rephrasing the keywords and the question here is why don't we actually put this suggestion into practice? I mean the keyword (inout) has no real meaning and it confuses any programmer. Let's be honest, what is the purpose of (inout)? Isn't it to create a mutable reference to what? We do not abbreviate a mutable reference to (mutref) because (mutref) is more readable, understandable, and more authentic in literal meaning than (inout). And why do we not rephrase the main word (borrowed) to (ref), as Chris Latner says. Let us take a simple example, but it conveys the meaning in a way. better:

let s: String = "Hello chris"
ref reference_to_string: String = s

Here's another example:

fn function(r1: ref String, r2: mutref String):
pass

fn main():
let s1: String = "Hello"
let s2: String = "chris"

function(s1, s2)

[rarebreed]

ref gets overloaded, both in rust, and in the way mojo's proposal syntax has it.

If you think about it, when we say or use "ref" we can be talking about two things:

• a type
• an operator (eg make a reference of something)

Therefore, I would prefer two different syntax forms to represent each concept. Instead of using ref as both the "type" and the "make this a reference to a value operator", there should be a different syntax form for each. For example, you could have this

x = "Hello world"    # no need for `let`.  Just assume immutable
y: Reference[a, String] = ref[a] x  
# or maybe 
y: Reference[a, String] = ref(a, x)  # looks like a function that returns a type (type constructor)
y: Reference[a, String] = ref[a, x]  # so it mirrors the type, but it looks too much like a python type eg tuple[a, x]

this way, the "special" syntax forms are reduced. ref (or ref[life]) is the "operator" form, and Reference[Lifetime, T] is the type.

As a model of what not to do, I hope they don't overload & and &mut like rust does (don't get me wrong, I really like rust, but I'm also not a RESF member, and have used rust long enough to see its warts). I wondered why rust took the kind of convoluted syntax it did. For those with C experience, they will immediately think of the & as "address of", and C++ people might think "address of" or a reference. And it's hard to disambiguate the meaning, because in rust, the & and &mut act as both a "type" and an "operator"..

let x: String = String::from("hello");
let y = &x;  // &x acts like an operator, and makes y a reference to x
let ref y = x;  // same as above.  this is actually more clear to me, but is not commonly seen in rust code

let mut z = String::from("again");
let bar: &mut String = &mut z;

ughh, that's kind of confusing honestly. And we haven't even used lifetimes yet. So in rust, & and &mut have double duty: The & (and &mut) can take either a type, or a value (as in let bar: &mut String = &mut z;)

So I hope that mojo makes it more clear with the distinction between a reference as a type, and as an operator.

[richardkiss]

an operator (eg make a reference of something)

Technically, this verb form for this operator is "dereference", which suggests deref.

[ivellapillil]

I actually like

y: Reference[a, String] = ref(a, x) # looks

For newcomers, concept of reference and pointers already are one level of indirection . If we introduce syntax that's overloaded it becomes much more harder for them as they need to decode multiple levels of syntax and semantics.

The one above is clear and lines nicely to the syntax they are already used to, so I think it would be easier for them .

May be lifetime should be towards the end as it sometimes can be elided.

y: Reference[String, a] = ref(x, a) # looks

[lattner]

FWIW, this proposal suggests removing let entirely: #1456