[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