Name the ~= (pattern matching?) operator when introducing it

[swift-ci]

Previous ID	SR-896
Radar	None
Original Reporter	douglashill (JIRA User)
Type	Improvement

Additional Detail from JIRA

Votes	1
Component/s	Standard Library
Labels	Improvement, Documentation
Assignee	None
Priority	Medium

md5: fccac19dc8668e07b859568b36ae3644

Issue Description:

Reading through the Swift book in iBooks, the ~= is mentioned but not named. There are numerous advantages to having a clear name:

• We can vocalise internally while reading and writing code. Many of us need to think using language: it is how we structure our thoughts.

• We can vocalise while speaking (rather than writing) to other people about Swift.

• Provides guidance on expected behaviours when overloading the operator.

• Names are easier to search for. Most search engines (including Google and Jira) seem to ignore ~=.

I am sorry if I am missing the name somewhere; it's hard to search for.

https://docs.swift.org/swift-book/documentation/the-swift-programming-language/patterns

[swift-ci]

Comment by Douglas Hill (JIRA)

Best suggestion I’ve header is ‘matches’.

[douglashill]

What was the resolution for this?

[Azoy]

Are you suggesting just a name for documentation purposes or something along the lines of renaming the ~= operator in source to something else? We can't do the latter anymore, and if you're suggesting the former then I'm not sure that's a standard library issue. I can reopen this if so, I'll just remove the standard library label.

[AnthonyLatsis]

We appear to have always referred to it as the pattern-matching operator in the compiler. The standard library does so too:

https://github.com/apple/swift/blob/c09fa4ef927c98a2c7d0393534f8e1e4e039cfbd/stdlib/public/core/Policy.swift#L352-L357

The book just says "operator" still. @Azoy Do you mind transferring this to swift-book?

[Azoy]

@AnthonyLatsis done

[amartini51]

Calling it the "pattern-matching operator" seems reasonable to me.

[amartini51]

Confirmed with Brian (who wrote the original version of this circa 2014) — there doesn't seem to be any reason to avoid naming this operator.