+1 completely agreed. I would also find it interesting to explore some sort of unified syntax the existing #line and the new #line, where I could read or write to it like (completely strawman syntax):
let line = #line // read #line = (number: 1, file: "/Users/jack/Desktop/coolswift.swift") // write
Jack
···
On Jan 22, 2016, at 2:09 PM, Joe Groff <jgroff@apple.com> wrote:
On Jan 22, 2016, at 2:04 PM, Jack Lawrence via swift-evolution <swift-evolution@swift.org> wrote:
I also use it in a similar way in playgrounds to inject some hidden preamble code and then rewrite the location of diagnostics.
Given the compiler-internal-ish nature of the existing `#line` feature (and since it's yet another thing copped from C with little consideration), I feel like we'd prefer to rename *that* if we had a better more mainstream use for the name #line.
On Jan 22, 2016, at 2:10 PM, Greg Titus via swift-evolution <swift-evolution@swift.org> wrote:
You could make these identifiers act like {get set} vars in order to support the current behavior of #line. E.g. LLDB and playgrounds would use `#line = 12; #file = “foo.swift”` instead of `#line 12 foo.swift`.
- Greg
On Jan 22, 2016, at 2:04 PM, Jack Lawrence via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
I also use it in a similar way in playgrounds to inject some hidden preamble code and then rewrite the location of diagnostics.
Jack
On Jan 22, 2016, at 1:48 PM, Jordan Rose <jordan_rose@apple.com <mailto:jordan_rose@apple.com>> wrote:
It's mainly used by LLDB to make sure user-visible line numbers make sense even in the presence of textually-inserted code.
Jordan
On Jan 22, 2016, at 13:43, Jack Lawrence via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
* using contextDictionary allows expandability and can subsume all existing context elements, indexed presumably by the same names
* renaming function to symbol takes care of self.dynamicType as well
* file and lineNumbers are gimmes
* column is apparently well liked by some (not going to kick someone's dog on this)
* adding module fills a big hole.
No tuples for Doug, covers some of Chris's points.
-- E
···
On Jan 24, 2016, at 4:12 PM, Remy Demarest <remy.demarest@gmail.com> wrote:
+1 I love the idea of having not-only consistent naming convention for compiler-magic code starting with #.
And I also love the idea that source location would be one object that you can print to get the full story while still retaining the possibility to use each individual components as needed, which is probably the rarer case. I never find myself wanting only some of properties and usually don't include them simply because it takes longer to write the format properly, if I can get them all in one go it's certainly a win.
That's cute, though it would behave quite differently from other properties, since you could only assign literals, and you could do so in any context. Not necessarily a showstopper problem, just an observation.
-Joe
···
On Jan 22, 2016, at 2:15 PM, Jack Lawrence <jackl@apple.com> wrote:
+1 completely agreed. I would also find it interesting to explore some sort of unified syntax the existing #line and the new #line, where I could read or write to it like (completely strawman syntax):
let line = #line // read #line = (number: 1, file: "/Users/jack/Desktop/coolswift.swift") // write
I'd prefer to use #line for this, and constrain the use of the current #line directive by context; like Chris said, we could require it to be the first thing after a newline, or we could adopt the `#line = ...` syntax a few people suggested.
-Joe
···
On Jan 26, 2016, at 1:48 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:
and calling it a day?
* using contextDictionary allows expandability and can subsume all existing context elements, indexed presumably by the same names
* renaming function to symbol takes care of self.dynamicType as well
* file and lineNumbers are gimmes
* column is apparently well liked by some (not going to kick someone's dog on this)
* adding module fills a big hole.
No tuples for Doug, covers some of Chris's points.
-- E
On Jan 24, 2016, at 4:12 PM, Remy Demarest <remy.demarest@gmail.com <mailto:remy.demarest@gmail.com>> wrote:
+1 I love the idea of having not-only consistent naming convention for compiler-magic code starting with #.
And I also love the idea that source location would be one object that you can print to get the full story while still retaining the possibility to use each individual components as needed, which is probably the rarer case. I never find myself wanting only some of properties and usually don't include them simply because it takes longer to write the format properly, if I can get them all in one go it's certainly a win.
* using contextDictionary allows expandability and can subsume all existing context elements, indexed presumably by the same names
* renaming function to symbol takes care of self.dynamicType as well
* file and lineNumbers are gimmes
* column is apparently well liked by some (not going to kick someone's dog on this)
* adding module fills a big hole.
No tuples for Doug, covers some of Chris's points.
* using contextDictionary allows expandability and can subsume all existing context elements, indexed presumably by the same names
* renaming function to symbol takes care of self.dynamicType as well
* file and lineNumbers are gimmes
* column is apparently well liked by some (not going to kick someone's dog on this)
* adding module fills a big hole.
No tuples for Doug, covers some of Chris's points.
-- E
On Jan 24, 2016, at 4:12 PM, Remy Demarest <remy.demarest@gmail.com <mailto:remy.demarest@gmail.com>> wrote:
+1 I love the idea of having not-only consistent naming convention for compiler-magic code starting with #.
And I also love the idea that source location would be one object that you can print to get the full story while still retaining the possibility to use each individual components as needed, which is probably the rarer case. I never find myself wanting only some of properties and usually don't include them simply because it takes longer to write the format properly, if I can get them all in one go it's certainly a win.
* using contextDictionary allows expandability and can subsume all
existing context elements, indexed presumably by the same names
* renaming function to symbol takes care of self.dynamicType as well
* file and lineNumbers are gimmes
* column is apparently well liked by some (not going to kick someone's dog
on this)
* adding module fills a big hole.
No tuples for Doug, covers some of Chris's points.
-- E
On Jan 24, 2016, at 4:12 PM, Remy Demarest <remy.demarest@gmail.com> > wrote:
+1 I love the idea of having not-only consistent naming convention for
compiler-magic code starting with #.
And I also love the idea that source location would be one object that you
can print to get the full story while still retaining the possibility to
use each individual components as needed, which is probably the rarer case.
I never find myself wanting only some of properties and usually don't
include them simply because it takes longer to write the format properly,
if I can get them all in one go it's certainly a win.
Remy Demarest
remy.demarest@gmail.com
Le 23 janv. 2016 à 18:46, Erica Sadun via swift-evolution < > swift-evolution@swift.org> a écrit :
One thing not mentioned about the current syntax of this obscure #line, is that you can use it on its own to reset to the real line numbers.
print(__LINE__) // Line 6 #line 2456 "filename"
print(__LINE__) // Line 2456 #line
print(__LINE__) // Line 10
The above currently doesn’t work in Playground (I’m guessing, lines are fed one by one to the compiler/interpreter), but does when properly compiled. So this new concept of using #line as a getter/setter will need a way to reset to real value.
Dany
···
Le 22 janv. 2016 à 17:17, Joe Groff via swift-evolution <swift-evolution@swift.org> a écrit :
On Jan 22, 2016, at 2:15 PM, Jack Lawrence <jackl@apple.com> wrote:
+1 completely agreed. I would also find it interesting to explore some sort of unified syntax the existing #line and the new #line, where I could read or write to it like (completely strawman syntax):
let line = #line // read #line = (number: 1, file: "/Users/jack/Desktop/coolswift.swift") // write
That's cute, though it would behave quite differently from other properties, since you could only assign literals, and you could do so in any context. Not necessarily a showstopper problem, just an observation.
* using contextDictionary allows expandability and can subsume all existing context elements, indexed presumably by the same names
* renaming function to symbol takes care of self.dynamicType as well
* file and lineNumbers are gimmes
* column is apparently well liked by some (not going to kick someone's dog on this)
* adding module fills a big hole.
No tuples for Doug, covers some of Chris's points.
Module information would be useful for a logging library, possibly to print the information but possibly also to allow different log levels (e.g. info, debug, warning, error, criticalError) to be configured for each module in a project so that log spam is manageable and possibly adjustable at runtime. (I have a fuller logging idea but have noted it is the example of out of scope and decided not to argue at this point).
Joseph
···
On Jan 26, 2016, at 11:58 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:
On Jan 26, 2016, at 1:48 PM, Erica Sadun <erica@ericasadun.com> wrote:
* using contextDictionary allows expandability and can subsume all existing context elements, indexed presumably by the same names
* renaming function to symbol takes care of self.dynamicType as well
* file and lineNumbers are gimmes
* column is apparently well liked by some (not going to kick someone's dog on this)
* adding module fills a big hole.
No tuples for Doug, covers some of Chris's points.
Module information would be useful for a logging library, possibly to print the information but possibly also to allow different log levels (e.g. info, debug, warning, error, criticalError) to be configured for each module in a project so that log spam is manageable and possibly adjustable at runtime. (I have a fuller logging idea but have noted it is the example of out of scope and decided not to argue at this point).
Ok, but why can’t you split that off the front of the symbol name? The advantage of providing a fully qualified symbol name is that it allows users of this feature to get exactly the information they want. Unlike my suggestion below, it should also include parameter type information, so it can identify overloads properly.
Splitting out module, type, method, or other information is prone to issues given that we allow nesting of types, nesting of functions, and perhaps nesting of modules some day. Providing all of the different things that clients could want seems like a never-ending problem.
-Chris
···
On Jan 26, 2016, at 6:13 PM, Joseph Lord <joseph@human-friendly.com> wrote:
Joseph
On Jan 26, 2016, at 11:58 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:
On Jan 26, 2016, at 1:48 PM, Erica Sadun <erica@ericasadun.com> wrote:
* using contextDictionary allows expandability and can subsume all existing context elements, indexed presumably by the same names
* renaming function to symbol takes care of self.dynamicType as well
* file and lineNumbers are gimmes
* column is apparently well liked by some (not going to kick someone's dog on this)
* adding module fills a big hole.
No tuples for Doug, covers some of Chris's points.
I have no strong feelings on the proposal, but I would like to confirm that the behavior will remain the same--this simply changes the name of these identifiers, is that correct?
I ask because swift-corelibs-xctest and the Objective-C XCTest SDK overlay use `__FILE__` and `__LINE__` as default parameters for assertion functions (see: https://github.com/apple/swift-corelibs-xctest/blob/73ff15ac353e6596bf314d66f90e1471043cf071/Sources/XCTest/XCTAssert.swift#L158\). These currently evaluate to the callsite of the function: calling `XCTAssert(true)` in a file named "Foo.swift" expands to `XCTAssertTrue(true, file: "Foo.swift")`.
As we attempt to replicate the Objective-C XCTest API in swift-corelibs-xctest, we're beginning to rely on these identifiers more (see: https://github.com/apple/swift-corelibs-xctest/pull/43\). It would be quite the setback if the behavior of the identifiers changed on us, so I just wanted to confirm that this proposal is only discussing naming, not behavior.
- Brian Gesiak
-1 I don’t mind how it reads, but Dictionaries return optionals.
···
On Tue, Jan 26, 2016 at 7:13 PM -0800, "Dave via swift-evolution" <swift-evolution@swift.org> wrote:
On Jan 26, 2016, at 15:44, Trent Nadeau via swift-evolution wrote:
Instead of #contextDictionary, what about #source. If it's a dictionary, I think that would read better:
The Swift-Evolution discussion of this topic took place in the "[Review] SE-0022: Referencing the Objective-C selector of a method" thread and then in its own "[Proposal] Eliminating Swift's Screaming Snake Case Identifiers" thread
Swift's pre-processor offers built-in __FILE__, __LINE__, __COLUMN__, and __FUNCTION__ identifiers. These expand to string and integer literals corresponding to a current location in source code. This feature provides high utility for logging, both tracing execution through logged messages and enabling developers to capture error context <http://ericasadun.com/2015/08/27/capturing-context-swiftlang/>\.
The current identifiers owe their syntax to C's __FILE__ and __LINE__ macros. These are built into C's preprocessor and expanded before running the C-language parser. Swift's implementation differs from C's but offers similar functionality and, unfortunately, similar symbols. This proposal aims to break free of the historic chains of their unsightly screaming camel case, which look like boa constrictors trying to digest <https://s-media-cache-ak0.pinimg.com/originals/59/ea/ee/59eaee788c31463b70e6e3d4fca5508f.jpg> fully swallowed keywords.
Using octothorpe-prefixed keywords offers several advantages:
They match the existing #available keyword (D. Gregor)
They match SE-0022's already-accepted selector(...) approach that reference a method's Objective-C selector (D. Gregor)
They support targeted code completion (D. Gregor)
They add a compiler-supported expression type that doesn't steal keywords, introducing a convention where # means "invoke compiler substitution logic here" (J. Rose)
They'd provide short-term solutions for a yet-as-undesigned macro system (D. Gregor)
<SE-00xx.md · GitHub design
This proposal renames the following identifiers:
__FILE__ -> #file
__LINE__ -> #line
__COLUMN__ -> #column
__DSO_HANDLE__ -> #dso_handle
This proposal eliminates __FUNCTION__. It introduces #symbol, (e.g. Swift.Dictionary.Init(x:Int,y:String)), which summarizes context including module, type, and function.
A fully qualified symbol enables users to access exactly the information they desire.
It should contain parameter type information to properly identify member overloads.
Each identifier will still expand at the call site, ensuring that the behavior matches that from the current suite.
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)"
}
}
<SE-00xx.md · GitHub with #context
A #context identifier would provide a compound type to provide a common well-defined tuple or struct summary of the current context with addressable elements. Offering addressable elements with a single identifier provides clean implementation. It permits developers to customize output based on current build settings without having to decompose the #symbol identifier output in logging routines.
Choosing which elements to represent could be problematic. Chris Lattner writes, "Splitting out module, type, method, or other information is prone to issues given that we allow nesting of types, nesting of functions, and perhaps nesting of modules some day. Providing all of the different things that clients could want seems like a never-ending problem."
In support of addressable elements, Joseph Lord writes, "Module information would be useful for a logging library, possibly to print the information but possibly also to allow different log levels (e.g. info, debug, warning, error, criticalError) to be configured for each module in a project so that log spam is manageable and possibly adjustable at runtime."
In support of summaries, Remy Demerest writes, "[I] love the idea that source location would be one object that you can print to get the full story while still retaining the possibility to use each individual components as needed, which is probably the rarer case. I never find myself wanting only some of properties and usually don't include them simply because it takes longer to write the format properly, if I can get them all in one go it's certainly a win."
Although the octothorpe-delineated #line identifier already exists in Swift for resetting line numbers (J. Lawrence), context can distinguish between uses. Joe Groff writes, "I'd prefer to use #line for this, and constrain the use of the current #line directive by context; like Chris said, we could require it to be the first thing after a newline, or we could adopt the #line = ... syntax a few people suggested."
···
On Jan 26, 2016, at 11:51 PM, Chris Lattner <clattner@apple.com> wrote:
On Jan 26, 2016, at 6:13 PM, Joseph Lord <joseph@human-friendly.com> wrote:
Module information would be useful for a logging library, possibly to print the information but possibly also to allow different log levels (e.g. info, debug, warning, error, criticalError) to be configured for each module in a project so that log spam is manageable and possibly adjustable at runtime. (I have a fuller logging idea but have noted it is the example of out of scope and decided not to argue at this point).
Ok, but why can’t you split that off the front of the symbol name? The advantage of providing a fully qualified symbol name is that it allows users of this feature to get exactly the information they want. Unlike my suggestion below, it should also include parameter type information, so it can identify overloads properly.
Splitting out module, type, method, or other information is prone to issues given that we allow nesting of types, nesting of functions, and perhaps nesting of modules some day. Providing all of the different things that clients could want seems like a never-ending problem.
-Chris
Joseph
On Jan 26, 2016, at 11:58 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:
On Jan 26, 2016, at 1:48 PM, Erica Sadun <erica@ericasadun.com> wrote:
* using contextDictionary allows expandability and can subsume all existing context elements, indexed presumably by the same names
* renaming function to symbol takes care of self.dynamicType as well
* file and lineNumbers are gimmes
* column is apparently well liked by some (not going to kick someone's dog on this)
* adding module fills a big hole.
No tuples for Doug, covers some of Chris's points.
This proposal does not change the behavior; #sourceLocation default arguments (or whatever we name it) will still be expanded at the call site. The Swift standard library depends on this fairly heavily, too.
- Doug
···
On Jan 26, 2016, at 7:41 PM, Brian Gesiak via swift-evolution <swift-evolution@swift.org> wrote:
I have no strong feelings on the proposal, but I would like to confirm that the behavior will remain the same--this simply changes the name of these identifiers, is that correct?
As we attempt to replicate the Objective-C XCTest API in swift-corelibs-xctest, we're beginning to rely on these identifiers more (see: https://github.com/apple/swift-corelibs-xctest/pull/43\). It would be quite the setback if the behavior of the identifiers changed on us, so I just wanted to confirm that this proposal is only discussing naming, not behavior.
Thanks for the proposal, Erica. I support the change. However, I prefer the #sourceLocation alternative syntax, though some compiler smarts around instantiation rather than embedding the old snake-case identifiers in the default arguments of the initializer.
That is, if I just wanted to reference the line number, I could write `#sourceLocation.line`, but if I wanted full context information I could use #sourceLocation, which would resolve to an instance of the struct. The compiler could use look ahead to avoid allocating the struct when only individual members are accessed. (Though perhaps the optimizer would make this front-end optimization unnecessary.)
In keeping with the proposal, I'd drop `function` from #sourceLocation in favor of `symbol`. I'm not familiar with how __DSO_HANDLE__ is used, so don't know whether it makes more sense as `#sourceLocation.dsoHandle` or whether it should stand alone. Assuming it belongs with the others, I'd suggest the #sourceLocation semantically represent an instance of a struct:
public struct SourceLocation: CustomDebugStringConvertible {
public let file: String
public let line: Int
public let column: Int
public let symbol: String
public let dsoHandle: String
public var debugDescription: String {
return "\(symbol):\(dsoHandle) @ \(file):\(line):\(column)"
}
}
As I said, I'm supportive of the proposal, but just have a preference for the alternative syntax. If folks don't want to go that direction, then perhaps some discussion of why not would strengthen the proposal.
If we stick with the proposal for multiple special identifiers, I think #dso_handle should be #dsoHandle. If we're going to kill the snake case, we should kill it dead.
(Regarding the #context approach, I don't think I fully understand it. I read the prior threads, but must have forgotten that bit. Is #context just an alternative to #symbol that provides NSURLComponents-like addressing of the pieces of the symbol? A concrete example of using #context would strengthen the argument against this option.)
Cheers,
Curt
···
-------------------------
Curt Clifton, PhD
Software Developer
The Omni Group www.curtclifton.net
On Jan 27, 2016, at 2:56 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:
This proposal aims to eliminate Swift's use of "screaming snake case" like __FILE__ and __FUNCTION__ and replacing identifier instances with common octothorpe-prefixed lower camel case #identifier representations.
The Swift-Evolution discussion of this topic took place in the "[Review] SE-0022: Referencing the Objective-C selector of a method" thread and then in its own "[Proposal] Eliminating Swift's Screaming Snake Case Identifiers" thread
Motivation
Swift's pre-processor offers built-in __FILE__, __LINE__, __COLUMN__, and __FUNCTION__ identifiers. These expand to string and integer literals corresponding to a current location in source code. This feature provides high utility for logging, both tracing execution through logged messages and enabling developers to capture error context.
The current identifiers owe their syntax to C's __FILE__ and __LINE__ macros. These are built into C's preprocessor and expanded before running the C-language parser. Swift's implementation differs from C's but offers similar functionality and, unfortunately, similar symbols. This proposal aims to break free of the historic chains of their unsightly screaming camel case, which look like boa constrictors trying to digest fully swallowed keywords.
Proposed solution
Using octothorpe-prefixed keywords offers several advantages:
They match the existing #available keyword (D. Gregor)
They match SE-0022's already-accepted selector(...) approach that reference a method's Objective-C selector (D. Gregor)
They support targeted code completion (D. Gregor)
They add a compiler-supported expression type that doesn't steal keywords, introducing a convention where # means "invoke compiler substitution logic here" (J. Rose)
They'd provide short-term solutions for a yet-as-undesigned macro system (D. Gregor)
Detailed design
This proposal renames the following identifiers:
__FILE__ -> #file
__LINE__ -> #line
__COLUMN__ -> #column
__DSO_HANDLE__ -> #dso_handle
This proposal eliminates __FUNCTION__. It introduces #symbol, (e.g. Swift.Dictionary.Init(x:Int,y:String)), which summarizes context including module, type, and function.
A fully qualified symbol enables users to access exactly the information they desire.
It should contain parameter type information to properly identify member overloads.
Each identifier will still expand at the call site, ensuring that the behavior matches that from the current suite.
Alternatives Considered
#sourceLocation
SR-198 requested the coalescing of the existing file, line, and function identifiers, potentially supporting a module representation as well. Andrew Bennett offered an initial design:
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)"
}
}
Summarizing with #context
A #context identifier would provide a compound type to provide a common well-defined tuple or struct summary of the current context with addressable elements. Offering addressable elements with a single identifier provides clean implementation. It permits developers to customize output based on current build settings without having to decompose the #symbol identifier output in logging routines.
Choosing which elements to represent could be problematic. Chris Lattner writes, "Splitting out module, type, method, or other information is prone to issues given that we allow nesting of types, nesting of functions, and perhaps nesting of modules some day. Providing all of the different things that clients could want seems like a never-ending problem."
In support of addressable elements, Joseph Lord writes, "Module information would be useful for a logging library, possibly to print the information but possibly also to allow different log levels (e.g. info, debug, warning, error, criticalError) to be configured for each module in a project so that log spam is manageable and possibly adjustable at runtime."
In support of summaries, Remy Demerest writes, "[I] love the idea that source location would be one object that you can print to get the full story while still retaining the possibility to use each individual components as needed, which is probably the rarer case. I never find myself wanting only some of properties and usually don't include them simply because it takes longer to write the format properly, if I can get them all in one go it's certainly a win."
Implementation notes
Although the octothorpe-delineated #line identifier already exists in Swift for resetting line numbers (J. Lawrence), context can distinguish between uses. Joe Groff writes, "I'd prefer to use #line for this, and constrain the use of the current #line directive by context; like Chris said, we could require it to be the first thing after a newline, or we could adopt the #line = ... syntax a few people suggested."
On Jan 26, 2016, at 11:51 PM, Chris Lattner <clattner@apple.com> wrote:
On Jan 26, 2016, at 6:13 PM, Joseph Lord <joseph@human-friendly.com> wrote:
Module information would be useful for a logging library, possibly to print the information but possibly also to allow different log levels (e.g. info, debug, warning, error, criticalError) to be configured for each module in a project so that log spam is manageable and possibly adjustable at runtime. (I have a fuller logging idea but have noted it is the example of out of scope and decided not to argue at this point).
Ok, but why can’t you split that off the front of the symbol name? The advantage of providing a fully qualified symbol name is that it allows users of this feature to get exactly the information they want. Unlike my suggestion below, it should also include parameter type information, so it can identify overloads properly.
Splitting out module, type, method, or other information is prone to issues given that we allow nesting of types, nesting of functions, and perhaps nesting of modules some day. Providing all of the different things that clients could want seems like a never-ending problem.
-Chris
Joseph
On Jan 26, 2016, at 11:58 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:
On Jan 26, 2016, at 1:48 PM, Erica Sadun <erica@ericasadun.com> wrote:
* using contextDictionary allows expandability and can subsume all existing context elements, indexed presumably by the same names
* renaming function to symbol takes care of self.dynamicType as well
* file and lineNumbers are gimmes
* column is apparently well liked by some (not going to kick someone's dog on this)
* adding module fills a big hole.
No tuples for Doug, covers some of Chris's points.
[..]
This proposal renames the following identifiers:
__FILE__ -> #file
__LINE__ -> #line
__COLUMN__ -> #column
__DSO_HANDLE__ -> #dso_handle
This proposal eliminates __FUNCTION__. It introduces #symbol, (e.g. Swift.Dictionary.Init(x:Int,y:String)), which summarizes context including module, type, and function.
A fully qualified symbol enables users to access exactly the information they desire.
It should contain parameter type information to properly identify member overloads.
Each identifier will still expand at the call site, ensuring that the behavior matches that from the current suite.
The fully qualified name could be quite long on occasion as I would expect it to include class hierarchy, nested class and nested function. So there might still be some usefulness in the brevity of a function (__FUNCTION__). Revealing the fully qualified name is useful for fixing bug and understanding the code flow, but some people could see it as a security concern, as it reveal how your code is structured.
On the brevity side, #file may benefit from a filename only version. I personally never liked seeing my user id in the output of __FILE__. On large project the filename only is not a perfect differentiator, but with __FUNCTION__ it is a nice starting point to find where the code reside ( find ./ -name FILE -exec grep -l FUNCTION {} \; ).
With the help of __LINE__, I start to even wonder if the calling signature (argument list) is even required as part of __FUNCTION__, but I don’t want to start long discussion on that topic, so I’ll drop the matter.
For #file, the user code can easily post-process the data and do an equivalent of basename(), but nonetheless the original __FILE__ has to be somewhere inside my final binary (and showing my user id)
For the #symbol, I do not think it would be that easy for user code to go extract the function name.
I think that keeping function should be added to this proposal (assuming other support the idea).
And that the #shortfile (or whatever name) should be investigated later as a distinct proposal (again based on support for the idea).
The current proposal should only avoid preventing the possibility of providing a short file version in the future
Just for the record, I started to reply wanting a really long #symbol for the hierarchy and nesting, and convinced myself that I only needed the bare function name, file name and line number to find where a log was generated. On some rare case, I guess I might need the column number (like in the nice example from David)
Although the octothorpe-delineated #line identifier already exists in Swift for resetting line numbers (J. Lawrence), context can distinguish between uses. Joe Groff writes, "I'd prefer to use #line for this, and constrain the use of the current #line directive by context; like Chris said, we could require it to be the first thing after a newline, or we could adopt the #line = ... syntax a few people suggested. »
Using the #line = … syntax would need a reset syntax (#line = resume | default | real), which could make such implementation a little more complex than the simple wording above suggest, a note to that effect should be added to the proposal.
Dany St-Amant
···
Le 27 janv. 2016 à 17:56, Erica Sadun via swift-evolution <swift-evolution@swift.org> a écrit :
As someone who has custom code in her error contextualization code for trimming file name's last component, I thoroughly understand the desire for short file. I would be happy to add it in.
The fully qualified name is left as an exercise for Apple, but I will update the proposal to include that concern, so it's there and ready for discussion.
I hear what you are saying about decomposing #symbol and will add that concern to the proposal.
-- Erica
···
On Jan 27, 2016, at 9:26 PM, Dany St-Amant <dsa.mls@icloud.com> wrote:
Le 27 janv. 2016 à 17:56, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit :
[..]
This proposal renames the following identifiers:
__FILE__ -> #file
__LINE__ -> #line
__COLUMN__ -> #column
__DSO_HANDLE__ -> #dso_handle
This proposal eliminates __FUNCTION__. It introduces #symbol, (e.g. Swift.Dictionary.Init(x:Int,y:String)), which summarizes context including module, type, and function.
A fully qualified symbol enables users to access exactly the information they desire.
It should contain parameter type information to properly identify member overloads.
Each identifier will still expand at the call site, ensuring that the behavior matches that from the current suite.
The fully qualified name could be quite long on occasion as I would expect it to include class hierarchy, nested class and nested function. So there might still be some usefulness in the brevity of a function (__FUNCTION__). Revealing the fully qualified name is useful for fixing bug and understanding the code flow, but some people could see it as a security concern, as it reveal how your code is structured.
On the brevity side, #file may benefit from a filename only version. I personally never liked seeing my user id in the output of __FILE__. On large project the filename only is not a perfect differentiator, but with __FUNCTION__ it is a nice starting point to find where the code reside ( find ./ -name FILE -exec grep -l FUNCTION {} \; ).
With the help of __LINE__, I start to even wonder if the calling signature (argument list) is even required as part of __FUNCTION__, but I don’t want to start long discussion on that topic, so I’ll drop the matter.
For #file, the user code can easily post-process the data and do an equivalent of basename(), but nonetheless the original __FILE__ has to be somewhere inside my final binary (and showing my user id)
For the #symbol, I do not think it would be that easy for user code to go extract the function name.
I think that keeping function should be added to this proposal (assuming other support the idea).
And that the #shortfile (or whatever name) should be investigated later as a distinct proposal (again based on support for the idea).
The current proposal should only avoid preventing the possibility of providing a short file version in the future
Just for the record, I started to reply wanting a really long #symbol for the hierarchy and nesting, and convinced myself that I only needed the bare function name, file name and line number to find where a log was generated. On some rare case, I guess I might need the column number (like in the nice example from David)
Although the octothorpe-delineated #line identifier already exists in Swift for resetting line numbers (J. Lawrence), context can distinguish between uses. Joe Groff writes, "I'd prefer to use #line for this, and constrain the use of the current #line directive by context; like Chris said, we could require it to be the first thing after a newline, or we could adopt the #line = ... syntax a few people suggested. »
Using the #line = … syntax would need a reset syntax (#line = resume | default | real), which could make such implementation a little more complex than the simple wording above suggest, a note to that effect should be added to the proposal.
Oh good gracious. Did I not change dso_handle to dsoHandle? I meant to. Will fix.
-- E
···
On Jan 27, 2016, at 10:47 PM, Curt Clifton <curt@omnigroup.com> wrote:
Thanks for the proposal, Erica. I support the change. However, I prefer the #sourceLocation alternative syntax, though some compiler smarts around instantiation rather than embedding the old snake-case identifiers in the default arguments of the initializer.
That is, if I just wanted to reference the line number, I could write `#sourceLocation.line`, but if I wanted full context information I could use #sourceLocation, which would resolve to an instance of the struct. The compiler could use look ahead to avoid allocating the struct when only individual members are accessed. (Though perhaps the optimizer would make this front-end optimization unnecessary.)
In keeping with the proposal, I'd drop `function` from #sourceLocation in favor of `symbol`. I'm not familiar with how __DSO_HANDLE__ is used, so don't know whether it makes more sense as `#sourceLocation.dsoHandle` or whether it should stand alone. Assuming it belongs with the others, I'd suggest the #sourceLocation semantically represent an instance of a struct:
public struct SourceLocation: CustomDebugStringConvertible {
public let file: String
public let line: Int
public let column: Int
public let symbol: String
public let dsoHandle: String
public var debugDescription: String {
return "\(symbol):\(dsoHandle) @ \(file):\(line):\(column)"
}
}
As I said, I'm supportive of the proposal, but just have a preference for the alternative syntax. If folks don't want to go that direction, then perhaps some discussion of why not would strengthen the proposal.
If we stick with the proposal for multiple special identifiers, I think #dso_handle should be #dsoHandle. If we're going to kill the snake case, we should kill it dead.
(Regarding the #context approach, I don't think I fully understand it. I read the prior threads, but must have forgotten that bit. Is #context just an alternative to #symbol that provides NSURLComponents-like addressing of the pieces of the symbol? A concrete example of using #context would strengthen the argument against this option.)
The Swift-Evolution discussion of this topic took place in the "[Review] SE-0022: Referencing the Objective-C selector of a method" thread and then in its own "[Proposal] Eliminating Swift's Screaming Snake Case Identifiers" thread
Swift's pre-processor offers built-in __FILE__, __LINE__, __COLUMN__, and __FUNCTION__ identifiers. These expand to string and integer literals corresponding to a current location in source code. This feature provides high utility for logging, both tracing execution through logged messages and enabling developers to capture error context <http://ericasadun.com/2015/08/27/capturing-context-swiftlang/>\.
The current identifiers owe their syntax to C's __FILE__ and __LINE__ macros. These are built into C's preprocessor and expanded before running the C-language parser. Swift's implementation differs from C's but offers similar functionality and, unfortunately, similar symbols. This proposal aims to break free of the historic chains of their unsightly screaming camel case, which look like boa constrictors trying to digest <https://s-media-cache-ak0.pinimg.com/originals/59/ea/ee/59eaee788c31463b70e6e3d4fca5508f.jpg> fully swallowed keywords.
Using octothorpe-prefixed keywords offers several advantages:
They match the existing #available keyword (D. Gregor)
They match SE-0022's already-accepted selector(...) approach that reference a method's Objective-C selector (D. Gregor)
They support targeted code completion (D. Gregor)
They add a compiler-supported expression type that doesn't steal keywords, introducing a convention where # means "invoke compiler substitution logic here" (J. Rose)
They'd provide short-term solutions for a yet-as-undesigned macro system (D. Gregor)
<SE-00xx.md · GitHub design
This proposal renames the following identifiers:
__FILE__ -> #file
__LINE__ -> #line
__COLUMN__ -> #column
__DSO_HANDLE__ -> #dso_handle
This proposal eliminates __FUNCTION__. It introduces #symbol, (e.g. Swift.Dictionary.Init(x:Int,y:String)), which summarizes context including module, type, and function.
A fully qualified symbol enables users to access exactly the information they desire.
It should contain parameter type information to properly identify member overloads.
Each identifier will still expand at the call site, ensuring that the behavior matches that from the current suite.
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)"
}
}
<SE-00xx.md · GitHub with #context
A #context identifier would provide a compound type to provide a common well-defined tuple or struct summary of the current context with addressable elements. Offering addressable elements with a single identifier provides clean implementation. It permits developers to customize output based on current build settings without having to decompose the #symbol identifier output in logging routines.
Choosing which elements to represent could be problematic. Chris Lattner writes, "Splitting out module, type, method, or other information is prone to issues given that we allow nesting of types, nesting of functions, and perhaps nesting of modules some day. Providing all of the different things that clients could want seems like a never-ending problem."
In support of addressable elements, Joseph Lord writes, "Module information would be useful for a logging library, possibly to print the information but possibly also to allow different log levels (e.g. info, debug, warning, error, criticalError) to be configured for each module in a project so that log spam is manageable and possibly adjustable at runtime."
In support of summaries, Remy Demerest writes, "[I] love the idea that source location would be one object that you can print to get the full story while still retaining the possibility to use each individual components as needed, which is probably the rarer case. I never find myself wanting only some of properties and usually don't include them simply because it takes longer to write the format properly, if I can get them all in one go it's certainly a win."
Although the octothorpe-delineated #line identifier already exists in Swift for resetting line numbers (J. Lawrence), context can distinguish between uses. Joe Groff writes, "I'd prefer to use #line for this, and constrain the use of the current #line directive by context; like Chris said, we could require it to be the first thing after a newline, or we could adopt the #line = ... syntax a few people suggested."
On Jan 26, 2016, at 11:51 PM, Chris Lattner <clattner@apple.com <mailto:clattner@apple.com>> wrote:
On Jan 26, 2016, at 6:13 PM, Joseph Lord <joseph@human-friendly.com <mailto:joseph@human-friendly.com>> wrote:
Module information would be useful for a logging library, possibly to print the information but possibly also to allow different log levels (e.g. info, debug, warning, error, criticalError) to be configured for each module in a project so that log spam is manageable and possibly adjustable at runtime. (I have a fuller logging idea but have noted it is the example of out of scope and decided not to argue at this point).
Ok, but why can’t you split that off the front of the symbol name? The advantage of providing a fully qualified symbol name is that it allows users of this feature to get exactly the information they want. Unlike my suggestion below, it should also include parameter type information, so it can identify overloads properly.
Splitting out module, type, method, or other information is prone to issues given that we allow nesting of types, nesting of functions, and perhaps nesting of modules some day. Providing all of the different things that clients could want seems like a never-ending problem.
-Chris
Joseph
On Jan 26, 2016, at 11:58 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Jan 26, 2016, at 1:48 PM, Erica Sadun <erica@ericasadun.com <mailto:erica@ericasadun.com>> wrote:
* using contextDictionary allows expandability and can subsume all existing context elements, indexed presumably by the same names
* renaming function to symbol takes care of self.dynamicType as well
* file and lineNumbers are gimmes
* column is apparently well liked by some (not going to kick someone's dog on this)
* adding module fills a big hole.
No tuples for Doug, covers some of Chris's points.
