Proposal: Simplifying `[addr me: Self*]` (self reference / copy accessing)

[CXCubeHD]

Introduction

The fact you need to declare [addr me: Self*] for a method is bad. That syntax looks very bloated and for a modern language just unnecessary.

My syntax proposal:

class Player
{
    // Accessing self using a mutatable reference (most common)
    fn GetAbilities(self) -> Abilities*
    {
        self.DoSomething(...);
        ...
    }

    // Accessing self using a mutatable reference (common)
    fn Move(write self, position: Vector3)
    {
        self.location = position;
        ...
    }
}

...

class Vector3
{
    // Accessing self using a copy of itself (very uncommon)
    fn Normalize(copy self) -> Vector3
    {
        ...
    }
}

Note that it would require a new keyword called self. Additionally there could be a write and copy keyword (can only be used with self), in order to clarify if the compiler should give out a mutable reference or a copy.

self can be naturally accessed using . instead of the ugly -> operator.

Since compilers from almost all languages place the self reference in the first parameter it would actually be very smart to also do that in Carbon, removing the need of placing (in most cases) unnecessary squarebrakets.

Aditional proposal:

self can be aliased naturally as an parameter:

...
fn MyMethod(myCoolAlias: write self, ...)
{
    myCoolAlias.myMember = "Hello!!!";
}

Thank you for reading, I really hope that Carbon will not have the existing boilerplate [addr me: Self*] syntax in its final release form.

Edit

Can you explain why you have blocked me jonmeow? I mean you can continue deleting my comments but that won't get us any further :/

At least you could give valid examples on why you blocked me, but there are none so why acting like that?

[jonmeow]

@CXCubeHD Using terms for mental illness as an insult is not consistent with our community. You're welcome and encouraged to provide data-based arguments, but insults and slurs are not welcome here.

[github-actions[bot]]

We triage inactive PRs and issues in order to make it easier to find active work. If this issue should remain active or becomes active again, please comment or remove the inactive label. The long term label can also be added for issues which are expected to take time. This issue is labeled inactive because the last activity was over 90 days ago.