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
proposal: Go 2: Allow question marks in function names #26111
Comments
It's not much better than the "Is-" idiom - e.g. |
If we adopt this, then why not |
The |
Regardless of whether you like the idiom or hate the idiom, whats so special about the question mark? If...
compiles because that character is part of UTF8, then why not the poor lowly ? It's also a readability thing - when your eyes are scanning a line you get to find out whats being looked at before learning its a boolean. e.g. (ruby)
|
世
is defined as a letter by unicode
?
is defined as a punctuation mark
…On 2 July 2018 at 11:37, Stephen Blackstone ***@***.***> wrote:
Regardless of whether you like the idiom or hate the idiom, whats so
special about the question mark?
If...
func 世 int() {
return 1
}
compiles because that character is part of UTF8, why not the poor lowly ?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#26111 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAAcA6g4gz7y7AH4-anCpOs555gUdamuks5uCXlrgaJpZM4U70Gp>
.
|
Compiles... :-) |
Unicode says that's a letter, https://www.compart.com/en/unicode/U+0242
…On 2 July 2018 at 11:53, Stephen Blackstone ***@***.***> wrote:
func helloɁ() {
fmt.Println("Hello!")
}
Compiles...
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#26111 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAAcAxX2NnttNPPmBfPwhEfhuo6m_C8bks5uCX0kgaJpZM4U70Gp>
.
|
Why is "letterhood" or "punctuationhood" relevant? The language doesn't include ternary expressions so its unlikely to be used in other contexts outside regex.. |
If I recall, some of the ideas for generics or similar use question marks. Those might not make it into the language, but it's always good to keep the door open. |
what is |
@sblackstone Whether a character is a letter or punctuation is relevant because that is what the spec says today. From https://golang.org/ref/spec#Identifiers: "An identifier is a sequence of one or more letters and digits. The first character in an identifier must be a letter." Letter is defined at https://golang.org/ref/spec#Letters_and_digits as anything that Unicode considers to be a letter, plus the underscore character. |
@ianlancetaylor I understand thats what the current spec says but thats why this is a proposal and not a bug report. |
Ah, sorry for misunderstanding. In that case I would say that whether a character is a letter or punctuation is relevant because we want to keep the spec simple. Why should we add an exception for |
Well, you could do what WDTE does and allow absolutely anything that isn't ambiguous with keywords and symbols. I'm just kidding. Don't do that. Please. Quite frankly, I think that allowing non-ASCII characters was a bit of a mistake in some way, though a minor one, as any use of, for example, Kanji in a function name in a library is going to be an absolute pain for anyone trying to use it that isn't used to typing those characters. The English alphabet is pretty well standardized in terms of ability to type it, though, so the reverse is not true. Thankfully, I've yet to see anyone do that, but the fact that #5763 exists means that someone at least had an interest, if, perhaps, only for internal use. That being said, I'm actually not against making exceptions for I don't know what I'm talking about here. Just kind of brainstorming out loud. |
I've always liked that Go uses punctuation for operators and letters for identifiers. (The one exception is the underscore character, which is in the “Punctuation, connector” category.) I could envision allowing more things in identifiers — such as combining marks (with suitable normalization), letterlike symbols, and perhaps emoji — but I feel pretty strongly that we should reserve the non-connector Punctuation and mathematical Symbols for (possible future) operators. Otherwise, where do we draw the line⸮ |
Even thought the // be careful pointerToVal will be changed
func SomFunc!(pointerToVal *Type) {
} |
It has an interesting meaning in certain programming languages (particularly those derived from Lisp), but it does not imply mutation in Go today, nor in English prose. That makes it much less obvious — especially to newcomers — than possible alternatives (such as a In contrast, |
We aren't going to do this. We aren't going to make an exception for one specific punctuation character. The current identifier rule is simple and there is no need to make it more complex. |
This comes from Ruby and its a real readability helper for functions that simply return booleans, e.g.
The text was updated successfully, but these errors were encountered: