You’re way overthinking this.
Just define a struct wrapping an UInt32 value, with a String initializer that expects a 4-byte ASCII value. Let it trap at runtime if someone passes in an invalid value.
let liga = Tag("liga")
There are already a million easy ways to write the initializer. (I’d start by iterating over the UTF-8 view.)
This is basically giving up on the entire premise of strong typing. a fair approach, but I wouldn’t consider it consistent with the vibe of the language. (keep in mind making collection length part of the type system is the primary motivation behind bringing fixed-size arrays to Swift.)
unrelated, but i bet there are two types of people: those who write loops for N = 4, those who do not, and those who use gyb
No, it doesn’t! It properly models such tags by a dedicated type, as opposed to a naked string literal or anonymous tuple.
struct Tag {
let value: UInt32
init(_ a: UInt8, _ b: UInt8, _ c: UInt8, _ d: UInt8) {
var value = UInt32(a)
value |= UInt32(b) &<< 8
value |= UInt32(c) &<< 16
value |= UInt32(d) &<< 24
precondition(value & 0x80808080 == 0)
self.value = value
}
init(_ string: String) {
var it = name.utf8.makeIterator()
self.init(it.next()!, it.next()!, it.next()!, it.next()!)
precondition(it.next() == nil)
}
}
// Alternative variant with SE-0247
struct Tag {
let value: UInt32
init(_ string: String) {
var string = string
self.value = string.withUTF8 { b in
precondition(b.count == 4)
return UInt32(b[0]) | (UInt32(b[1]) &<< 8) |
(UInt32(b[2]) &<< 16) | (UInt32(b[3]) &<< 24)
}
precondition(value & 0x80808080 == 0)
}
No, but if that were true I would expect people to be prepared for a lot of proposals to be simply swatted away by the Core Team and the people that own that area (I cannot imagine that the Apple side of things would not have one person or several more able to be an authority on any single part of the language... I expect the community engagement to rise in the language design even further and that should stabilise things even more).
The argument to the initializer is still stringly typed. When there are this many ways for the initializer body to fail (i count four !s and one precondition), that’s an indicator that this init should really be an init? instead. But I think we’re getting way off topic here.
actual question, does Swift define order of evaluation for function arguments? I found this post from Chris in 2015 when he said it’s defined left-to-right for operators, but i couldn’t find anything for function arguments.
it’s alluded to in SE-0004. really should be written down somewhere properly tho
The core team met to discuss the review thread, and did indeed conclude that the proposal should be returned for further revision. To help focus that discussion, the core team would like to provide some additional direction in terms of how they'd like to see the issues resolved, and which directions are more or less likely to be accepted in a future proposal, hence I haven't posted the final decision quite yet. Please bear with me.
In the mean time, there's some good ongoing discussion here, and I'd recommend moving over to the evolution discussion topic.
It is important to have a literal syntax for Unicode.Scalar but not for Character for the reasons I’ve already enumerated above; so, it is more important than Character in this sense. That doesn’t imply anything at all about the success or failure of Swift’s design for strings. Nothing about indexing the extended grapheme clusters of a string by default is tied to what a single-quoted literal should mean.
Sure, it's understood that some people find it quite important to have a literal syntax that defaults to Unicode.Scalar, I just continue to disagree haven't found the arguments persuasive. Character is inherently so much more important than Unicode.Scalar to me, so I will be difficult to convince. So far, in terms of addressing the use cases from the proposal, the main upside of making single-quoted literals default to Unicode.Scalar seems to be that a hypothetical trapping .ascii property is more hidden than if it was available on Character.
this is not about discovery,, 'a'.ascii is impossible if single quoted literals default to anything but Unicode.Scalar, since we only do member lookups on the default literal type.
Maybe I'm confused, but if .ascii was on Character instead of Unicode.Scalar then 'a'.ascii should work fine with single-quoted literals defaulting to Character.
Sure, but that's both a separate issue to the use here for literals, already applies to the existing asciiValue property, and is also self-admittedly “arguable”. Misuse in this context would be theoretically diagnosable at compile-time in the same way that let s: UnicodeScalar = "\r\n" is.
such an api would also be callable on opaque run-time values.
Sure, of course, and so would the API on Unicode.Scalar. Going back to my original point:
That is neither the main upside, nor (in my view) even a consideration at all.
The main upside of using single-quoted literals for Unicode scalars is that it improves the ergonomics of operations on Unicode scalars. There are many more of these than there are on extended grapheme clusters (characters).
Perhaps, though the current number of operations available on Unicode scalars doesn't seem like the right criteria at all, or do you mean that doing operations on Unicode scalars is more common? I'm suspicious of the latter, and the former just takes me back to an even earlier point, from my first post in this thread:
It's not clear to me what the common operations around Character would be that need significant ergonomic improvement. For example, you can already do things like someString.first == "c", with compile-time validation that the right-hand side is a Character—changing to single quote delimiters wouldn't significantly improve the ergonomics of this particular API. Are there things that users want to do with Character right now that would be significantly easier with single quotes?
On the other hand, there are certainly operations involving Unicode scalars that are painful right now which would get significant ergonomic improvement from a single-quote representation. The ASCII encoding examples are one such example.
So the question should not be whether Unicode.Scalar is more useful than Character to Swift users. Rather, we should be asking which option gives the most significant usability improvement for cases that are currently painful. And under that light, it seems to me that using single quotes to represent a Unicode.Scalar has greater utility.
But, again, defaulting to Unicode.Scalar doesn't particularly improve the ASCII examples over defaulting to Character. The hypothetical trapping .ascii property could be available on either type. If you want to optimise for that narrow use case, then you should advocate for single-quoted literals being effectively integer literals (possibly restricted to ASCII) or a new ASCII type or something similar.
Unicode.Scalar and Character model separate Unicode concepts; one is not a generalization of the other, and APIs appropriate on one of these are not necessarily appropriate on the other—and in fact many are not.
As we have discussed above, ascii is not appropriate for Character because '\r\n' is a single extended grapheme cluster with a multibyte ASCII representation.
It’s currently not possible to validate Characters, only Unicode.Scalars. This is a minor argument in favor of 'a' for Unicode.Scalar and below, as single quotes could denote statically verifiable literals, and double quotes could denote platform-dependent literals. But, when Swift gets rid of the ICU dependency, this will no longer be true, and Characters will be statically verifiable too.