Go: proposal: Go 2: Allow question marks in function names

[sblackstone]

This comes from Ruby and its a real readability helper for functions that simply return booleans, e.g.

type OptionContract struct {
  Right string
}

func (oc *OptionContract) put?() bool {
  return oc.Right == 'P'
}

var (
  oc OptionContract
)

oc.right = 'P'

oc.put?() // True

[ALTree]

It's not much better than the "Is-" idiom - e.g. IsPrime - (in fact, personally I prefer the Is idiom over the ? idiom) and at the same time this would require complicating the rules for valid variable names (that right now are quite simple). Not sure it's worth it.

[ianlancetaylor]

If we adopt this, then why not ¿Poner? ? As @ALTree says, the current rules are simple.

[as]

The put? is very confusing, but isPut doesn't help either.

[sblackstone]

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, 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)

if option.call? && option.long? // Do something particular.

[davecheney]

世

is defined as a letter by unicode

?

is defined as a punctuation mark

On 2 July 2018 at 11:37, Stephen Blackstone [e-mail]
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
https://github.com/golang/go/issues/26111#issuecomment-401649582, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAcA6g4gz7y7AH4-anCpOs555gUdamuks5uCXlrgaJpZM4U70Gp
.

[sblackstone]

func helloɁ() {
    fmt.Println("Hello!")
}

Compiles... :-)

[davecheney]

Unicode says that's a letter, https://www.compart.com/en/unicode/U+0242

On 2 July 2018 at 11:53, Stephen Blackstone [e-mail]
wrote:

func helloɁ() {
fmt.Println("Hello!")
}

Compiles...

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/26111#issuecomment-401651216, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAcAxX2NnttNPPmBfPwhEfhuo6m_C8bks5uCX0kgaJpZM4U70Gp
.

[sblackstone]

Why is "letterhood" or "punctuationhood" relevant?

The language doesn't include ternary expressions so its unlikely to be used in other contexts outside regex..

[Azareal]

If I recall, some of the ideas for generics or similar use question marks.
There were also some ideas for error handling which tossed question marks in.

Those might not make it into the language, but it's always good to keep the door open.
Plus, if question marks are valid, then I don't see why every other pieces of punctuation shouldn't be (not that it's practical to do so), otherwise you have to keep track of which ones are legal and which are not.

[davecheney]

Plus, if question marks are valid, then I don't see why every other pieces of punctuation shouldn't be (not that it's practical to do so), otherwise you have to keep track of which ones are legal and which are not.

x, y := package.a,b,c

what is x? It is the function package.a,b or is it the function package.a and y is the local variable b,c.

[ianlancetaylor]

@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.

[sblackstone]

@ianlancetaylor I understand thats what the current spec says but thats why this is a proposal and not a bug report.

[ianlancetaylor]

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 ? ? As I tried to get at with my Spanish example above, there are many similar punctuation characters. Once we start treating some punctuation characters as valid identifier characters, where do we stop? What principle do we follow? I think this is also what @Azareal was getting at above.

[DeedleFake]

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 ? and !, exceptions that would be much simpler to specify with an ASCII base for allowed characters. I used Ruby for a while and, once I got used to it, I do have to agree that the ? and ! conventions for 'query' and mutating methods, respectively, were quite nice. Go technically already has a weakly enforced form of the latter, at least in terms of methods on struct types, via pointer of non-pointer receivers, but I wouldn't be against a more official and cleaner way of specifying the classes of behavior a function is designed for like that.

I don't know what I'm talking about here. Just kind of brainstorming out loud.

[bcmills]

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⸮

[g13013]

Even thought the ? character can be replaced by Is prefix, the special ! one has a very interesting meaning, especially that Go does not allow immutability yet

// be careful pointerToVal will be changed
func SomFunc!(pointerToVal *Type) {

}

[bcmills]

@g13013

the special ! one has a very interesting meaning

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 Set prefix).

In contrast, ? at least implies a question in prose.

[ianlancetaylor]

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.