Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rename me -> self #1382

Merged
merged 22 commits into from
Dec 6, 2022
Merged
Changes from 18 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
108 changes: 108 additions & 0 deletions proposals/p1382.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,108 @@
# Rename `me` -> `self`

<!--
Part of the Carbon Language project, under the Apache License v2.0 with LLVM
Exceptions. See /LICENSE for license information.
SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
-->

[Pull request](https://github.com/carbon-language/carbon-lang/pull/1382)

<!-- toc -->

## Table of contents

- [Problem](#problem)
- [Background](#background)
- [Proposal](#proposal)
- [Rationale](#rationale)
- [Alternatives considered](#alternatives-considered)
- [Don't change anything](#dont-change-anything)
- [`this`](#this)

<!-- tocstop -->

## Problem

We've tried the `fn MethodName[me: Self]()` syntax for a while, and from our
experience the brevity of `me` is not worth doing something novel in this space.
We have found that `me` doesn't read well in practice.

## Background

The current method syntax, including these choices, was decided in
questions-for-leads issue
[#494: Method syntax](https://github.com/carbon-language/carbon-lang/issues/494)
and implemented in proposal
[#722: Nominal classes and methods](https://github.com/carbon-language/carbon-lang/pull/722).

Looking at other languages that use reserved word for the receiver value:

| When | Language | Receiver when<br />accessing members | Receiver value | Receiver type |
| ---------- | ---------- | ------------------------------------ | -------------- | ------------- |
| 1983 | C++ | implicit | `this` | --- |
chandlerc marked this conversation as resolved.
Show resolved Hide resolved
| 1991 | Python | explicit | `self` | --- |
| 1995 | Java | implicit | `this` | --- |
| 1995 | JavaScript | explicit | `this` | --- |
| 2000 | C# | implicit | `this` | --- |
| 2009 | Go | explicit | (see below) | --- |
| 2010 | Rust | explicit | `self` | `Self` |
| 2011 | Kotlin | implicit | `this` | --- |
| 2012 | TypeScript | explicit | `this` | `this` |
| 2014 | Swift | implicit | `self` | `Self` |
| previously | Carbon | explicit | `me` | `Self` |
| proposed | Carbon | explicit | `self` | `Self` |

In detail:

- C++ uses
[`this` for address of the receiver value](https://en.cppreference.com/w/cpp/language/this)
- Swift uses
[`self` for the receiver value](https://docs.swift.org/swift-book/LanguageGuide/Methods.html#ID238).
and
[`Self` for its type](https://docs.swift.org/swift-book/ReferenceManual/Types.html#ID610).
- Rust uses
[`self` for the receiver value](https://doc.rust-lang.org/std/keyword.self.html)
and
[`Self` for its type](https://doc.rust-lang.org/rust-by-example/fn/methods.html).
- C# uses
[`this` for a reference to the receiver value](https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/this)
- Python as a convention uses `self` for the receiver value, but it's almost
universally followed.
- Go conventionally uses an abbreviation of the type name.

## Proposal

Use `self` instead of `me` to be consistent with Swift and Rust.

## Rationale

This is consistent with Carbon's goal to make
[Code that is easy to read, understand, and write](/docs/project/goals.md#code-that-is-easy-to-read-understand-and-write)
by choosing a keyword for this role that is less surprising to users.

## Alternatives considered

### Don't change anything

We could stay with the status quo, which has the benefit that `me` is shorter
than `self`. There are two considerations:

- For accessing members of the current object, the chart in
[the background section](#background) shows plenty of precedent for
requiring a 4 character explicit keyword.
- We would also like to reduce ceremony when declaring the signature of a
method. For this concern, both `me: Self` and `addr me: Self*` are already
longer than what other languages use in practice. It would probably be
better to solve this problem with a shortcut approach like Rust
([1](https://doc.rust-lang.org/book/ch05-03-method-syntax.html),
[2](https://doc.rust-lang.org/rust-by-example/fn/methods.html)), where
`&self` is short for `self: &Self` and `&mut self` is short for
`self: &mut Self`.

### `this`

We could also switch to `this`, primarily to benefit
[C++ users](https://en.cppreference.com/w/cpp/language/this). However, we are
worried that it frequently not being a pointer would be surprising to those C++
users.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this rationale should be expanded because of the break in consistency with C++. Yes, it won't always be the same type: but most C++ developers are familiar with the basic meaning of this, and the type would be in the function signature.

For example, although you don't note the rationale here, I think you'd noted that self operates this way in Rust. However, that's Rust, and most C++ developers shouldn't be expected to be familiar with it. The surrounding syntax also differs from Rust, which I would expect to hamper experienced Rust devs.

As a counterpoint to the Rust type argument, more likely C++ developers would be familiar with self in Python, due to its popularity, and it's always the same type there. From what I can tell, Swift is similar. Thus I don't see self as offering better cross-language consistency from a type perspective, since Rust is in a minority.

I believe more information should be provided for the leads here -- it may even be appropriate to raise the question for explicit resolution, although it's perhaps redundant with this proposal.

Copy link
Contributor

@Pixep Pixep Jul 25, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the 'cons' colums, from a semantic standpoint, it feels less clear that this refers to the current instance. self feels like it is less ambiguously refer 'itself' vs designating something with 'this'/'that'.

Copy link

@emlai emlai Jul 26, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • we are worried that it frequently not being a pointer would be surprising to those C++ users

    Could expand this alternative to also suggest relying on user feedback on whether this not being a pointer would actually be surprising, rather than assumption.

  • This applies to pretty much all syntax changes from C++, but: could mention the language strangeness budget i.e. the balancing of seemingly small syntax changes like this versus the more major changes we're planning to make.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One other point that may be worth capturing here is that we view it as an advantage to use the same spelling for the variable self as for the type Self, and while this might make an acceptable name for the object parameter, Self is much more strongly established as the name for the current class, for example in PL research, and there is no precedent for a type named This.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've expanded in this update: fda1ceb

Copy link
Contributor

@micttyl micttyl Dec 6, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(research is already done in the proposal)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've added that link to history in the background section: see 2b7ee5a