True, though we could make it a tuple or invent a new SourceLocLiteralConvertible protocol. However, Andrew Bennett suggested an interesting approach in Issues · apple/swift-issues · GitHub
public struct SourceLocation {
init(file: String = __FILE__, line: Int = __LINE__, column: Int = __COLUMN__, function: String = __FUNCTION__) {
self.file = file
self.line = line
self.column = column
self.function = function
}
public var file: String
public var line: Int
public var column: Int
public var function: String
}
If we apply the default argument rules for #line, #column, etc. at depth, so that if you use 'SourceLocation()' as a default parameter you get the caller's source location as default arguments to SourceLocation(), then you could build aggregate source location structures from the primitives we have today.
-Joe
···
On Jan 22, 2016, at 11:42 AM, Jordan Rose <jordan_rose@apple.com> wrote:
On Jan 21, 2016, at 21:44, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:
On Jan 21, 2016, at 9:25 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:
Okay, you know this was coming: let's Groff this thing.
How about #(line) where you can decouple the specific compiler implementation bits from the keyword bits without hardcoding support, enabling implementation of, for example, #(runcible) for future Swift compiler substitution logic.
If you're going to bring me into it…I would prefer coalescing all these __FILE__, __LINE__, etc. things into one #sourceLocation structure. If you want one source-location-related thing, you tend to want the others, and you also want to be able to forward the source location info easily through the depths of your assertion/logging framework.
The downside is that this becomes Yet Another Compiler-Known Type and Yet Another Thing In the Standard Library. All the current fields are string literals and integer literals.