Comment by Andrew Bennett (JIRA)

public struct SourceLocation: CustomDebugStringConvertible {
 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 let file: String
 public let line: Int
 public let column: Int
 public let function: String

 public var debugDescription: String {
     return "\(function) @ \(file):\(line):\(column)"
 }
}

Comment by Andrew Bennett (JIRA)

Usage:

let location = SourceLocation()
print("\(location)")
print("\(location.file)")

Interesting, bnut (JIRA User). We could make this a library feature if the language rules for expanding __FILE__ as default values applied at depth, so that func foo(sourceLoc: SourceLocation = SourceLocation()) would instantiate SourceLocation()'s own defaulted arguments from the caller's source location.

Comment by Marc Knaup (JIRA)

Wouldn't that result in the binary containing ALL information (file, line, column and function) even if I am only interested in a single item (e.g. just the line number)? I don't think that such a behavior would be desired.

If that problem can be avoided then I'd like to also request two additional elements:

• module: the containing Swift module's name

• type: if you just have the function name you can't tell whether it's a global function, a specific type's function and which type's function. A single Swift file can contain multiple types. `type` could be the demangled name of the function's containing type. nil or empty if it's a global function.