carbon-lang
carbon-lang copied to clipboard
carbon-language
Rename `me` -> `self`
Carbon has been using a me: Self or addr me: Self* deduced parameter to mark a function as a method as decided in #494 and implemented in #722 . This does not match existing languages, and so this proposal switches me to self to match Python, Rust, and Swift.
Seems that you guy misunderstand...carbon doesn't have
selfkeyword, soMeis just a naming style, it doesn't matter...
I have added self to the list of keywords in this proposal.
I think a strong argument in favour of this proposal is that it ensures that the type and value have the same name, which seems to be an industry standard when both exist.
You might consider splitting all the misc file changes to a separate PR in order to make it simpler to get feedback.
Okay I will figure out how to do that.
You might consider splitting all the misc file changes to a separate PR in order to make it simpler to get feedback.
Okay I will figure out how to do that.
Moved implementation of proposal to #1624
Is it really necessary to have a keyword here ? Python is cited here, but in python, self is not a keyword. Any name can be used as first argument to make a method.
In carbon, the rule could be that a function within class that has first argument of type Self is a method. This leaves it to the programmer to choose which argument name is better suited, and makes one fewer keywords in the language.
Is it really necessary to have a keyword here ? Python is cited here, but in python, self is not a keyword. Any name can be used as first argument to make a method.
In carbon, the rule could be that a function within class that has first argument of type Self is a method. This leaves it to the programmer to choose which argument name is better suited, and makes one fewer keywords in the language.
Making the receiver type has already been considered: https://github.com/carbon-language/carbon-lang/blob/trunk/proposals/p0722.md#full-receiver-type
When we review proposals, we try not to rehash decided issues. Since there is a decision there will be a receiver type, and this PR is about the name, please don't continue this thread here: it's off-topic.
That said, I don't see any recent issue asking the leads about removing the receiver type. If you want to suggest a change to remove the receiver type, a good way to start is by creating a new issue, putting it under the "Issues for leads" project, and providing a rationale for making it optional that offers new information not previously considered. In the FAQ, this section has some pertinent notes on revisiting decisions.
There's a discussion about the receiver type notation: https://github.com/carbon-language/carbon-lang/discussions/1777. It could be turned into an issue for leads or a proposal, at some point. Might need some fleshing out though.
For me, the most convincing reason to change the spelling of me to self would be to support shorthand syntax [self] and [addr self], which don't really make so much sense when the value and the type are spelled differently. And the most significant reason to not make this change is because in the absence of a shorthand syntax, it makes the method introduction syntax unpalatably long. So I see the change in spelling of me -> self and the addition of a shorthand syntax as being coupled: I'd want us to do either neither or both.
Would it be reasonable to also add the shorthand syntax in this proposal?
For me, the most convincing reason to change the spelling of
metoselfwould be to support shorthand syntax[self]and[addr self], which don't really make so much sense when the value and the type are spelled differently. And the most significant reason to not make this change is because in the absence of a shorthand syntax, it makes the method introduction syntax unpalatably long. So I see the change in spelling ofme->selfand the addition of a shorthand syntax as being coupled: I'd want us to do either neither or both.Would it be reasonable to also add the shorthand syntax in this proposal?
@chandlerc How would you feel about this proposal with the shorthand syntax included?
For me, the most convincing reason to change the spelling of
metoselfwould be to support shorthand syntax[self]and[addr self], which don't really make so much sense when the value and the type are spelled differently. And the most significant reason to not make this change is because in the absence of a shorthand syntax, it makes the method introduction syntax unpalatably long. So I see the change in spelling ofme->selfand the addition of a shorthand syntax as being coupled: I'd want us to do either neither or both. Would it be reasonable to also add the shorthand syntax in this proposal?@chandlerc How would you feel about this proposal with the shorthand syntax included?
I would prefer to revisit the syntax holistically, and once we have #1974 in the design. Before that, I would prefer to not add a shorthand syntax -- I think it forces us to think through implications of the shorthand syntax without much benefit as we'll have to do that again if we do a more holistic revisit.
I don't feel strongly about the 2 character difference between me and self. I think with either name, the syntax is too long -- addr self: Self* is 16 characters instead of 14 characters of today's addr me: Self*.
I think the much easier thing to decouple from a holistic revisit of the syntax, including shorthand syntax, is the name. That is also the part that I think causes much more confusion when discussing and writing examples. It also impacts the body of code, not just the signature, and so is a bit more annoying to update later. So overall, I'd prefer to go ahead and switch to self now, but not spend time trying to come up with a shorthand syntax.
@zygoloid - Any thoughts on my comments?
Let's move forward with this proposal and see if we get negative feedback on verbosity, and look at handling any such feedback once we have that experience.