[swift-evolution] Proposal: String literal suffixes for defining types

Michel Fortin michel.fortin at michelf.ca
Sat Dec 12 06:55:34 CST 2015


Le 11 déc. 2015 à 0:52, Chris Lattner via swift-evolution <swift-evolution at swift.org> a écrit :

> On the other hand: I haven’t heard this be a wide-spread complaint.  It smacks of the “123ull” sorts of suffixes in C, which are pretty grotty IMO.  It reduces clarity of code by introducing syntax magic.

Speaking of syntax magic, I can't say I really had a need for suffixes, but that's because I could to resort to this on occasion:

	extension UTF16Char : UnicodeScalarLiteralConvertible {
		public init(unicodeScalarLiteral value: UnicodeScalar) {
			assert(UTF16Char.isRepresentable(value))
			self.init(Int16(value.value))
		}
		public static func isRepresentable(unicodeScalar: UnicodeScalar) -> Bool {
			switch unicodeScalar.value {
			case 0x0000 ... 0xD7FF: return true
			case 0xE000 ... 0xFFFF: return true
			default: return false
			}
		}
	}

... allowing me to do things of this sort in a way that isn't overly verbose:

	func hexvalue(digit: UTF16Char) -> UInt16? {
		switch digit {
			case "a" ... "f": return digit - "a" + 0xA
			case "A" ... "F": return digit - "A" + 0xA
			case "0" ... "9": return digit - "0"
			default:          return nil
		}
	}

I only wish I could keep that "UnicodeScalarLiteralConvertible" conformance extension private within the file instead of leaking it everywhere. I guess a prefix would improve things if it allowed me to keep it private.

-- 
Michel Fortin
michel.fortin at michelf.ca
https://michelf.ca



More information about the swift-evolution mailing list