[swift-evolution] [Idea] Custom keywords for operators.

[David Sweeris]

Sent from my iPad
> On Jul 31, 2017, at 2:09 PM, Gor Gyolchanyan via swift-evolution <swift-evolution at swift.org> wrote:
> 
> So I was thinking the other day (and by "the other day" I mean "It just occurred to me") that Swift's custom operator declaration mechanism is pretty sweet (it's become even sweeter ever since numeric precedence values were replaced with purely relativistic precedence trees). There are currently only two problems with them that grind my operator-declaring endeavors to a painful halt:
> 	1. The fact that most punctuation characters on the keyboard (think - ASCII) are reserved, so any custom operator either has to be a long sequence of two or three non-reserved ASCII characters or have to include difficult-to-type unicode punctuation characters.
> 	2. The fact that anything that passes as an identifier character (which includes a surprisingly wide array of punctuation characters) is off the table as well.
> 
> I have no good idea how to deal with the first problem

Unicode has a lot of operator characters. If the one you want isn't already easy to type, you can use a utility like Ukelele (http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&id=ukelele) to map them to some unused key combination (on macOS, anyway... dunno what the Linux/Windows equivalent is).



> but the second problem seems to have a bafflingly simple solution that I can't believe I haven't noticed until now.
> And the reason to even try to solve that problem is because Swift already has a lot of operators with identifiers in them:
> 	* infix is
> 	* infix as
> 	* infix as?
> 	* infix as!
> 	* prefix try
> 	* prefix try?
> 	* prefix try!
> 	* prefix throw
> So this is hardly a new concept to Schwifty developers.
> 
> The way I think could this could be solved is by introducing custom keywords that can be defined just like custom operators can be.
> The custom keyword has to be a valid identifier and is defined much like a non-infix custom operator (by writing `keyword`, followed by an identifier).
> 
> Custom operator definitios would now be permitted to have any number of non-adjacent keywords among usual punctuation characters.
> Any identifier that matches a custom keyword has to be escaped with backticks just like it's the case for regular keywords.
> Prefix operators may not end with a keyword.
> Postfix operators may not begin with a keyword.
> Infix operators that either begin or end with a keyword may not be used without whitespaces.

I wouldn't be opposed to just requiring whitespace around infix operators in general (but I suspect I'm in the minority on that).

> Here's an example:
> 
> precedencegroup AggregateFormingPrecedence {
> 	higherThan: TernaryPrecedence
> 	lowerThan: LogicalDisjunctionPrecedence
> }
> 
> precedencegroup DimensionFormingPrecedence {
> 	higherThan: AggregateFormingPrecedence
> 	lowerThan: LogicalDisjunctionPrecedence
> }
> 
> keyword of
> keyword by
> infix operator of: AggregateFormingPrecedence
> infix operator by: DimensionFormingPrecedence
> 
> public struct Matrix<Element> where Element: FloatingPoint {
> 
> 	public struct Dimensions {
> 		let rows: Int
> 		let columns: Int
> 	}
> 
> 	public init(dimensions: Dimensions, value: Element) {
> 		self.elements = .init(repeating: value, count: dimensions.rows * dimensions.columns)
> 	}
> 
> 	private var elements: [Element]
> 	
> }
> 
> public static func by(_ rows: Int, _ columns: Int) -> Matrix.Dimensions {
> 	return .init(rows: rows, columns: columns)
> }
> 
> public static func of<Element>(_ dimensions: Matrix.Dimensions, _ value: Element) -> Matrix<Element> where Element: FloatingPoint {
> 	return .init(dimensions: dimensions, value: value)
> }
> 
> let m = 3 by 4 of 1.0 // m is of type Matrix<Double>
> 
> I feel like these kind of changes would be best considered in the early stages of a major release (namely, Swift 5) so that they have time to be refined and tested.
> What do you guys think?

The topic of using identifiers as operators has come up before, and rejected on the grounds that it'd make parsing things much slower. I don't recall if your ideas regarding restrictions on the spellings have been discussed, though.

I'm +1 if the technical issues can be sorted out.

- Dave Sweeris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170731/7a7e9f98/attachment.html>