Module-relative path seems to be most highly requested.
If you google for __FILE__ and lastPathComponent, clearly I'm not the only one out there who would be happy for the convenience but so far I have not heard any voice on-list support the idea.
As for function, which returns a string, at a minimum, wouldn't it be better to return a GregorString (UIView.insertSubview(_:at:)) vs a __FUNCTION__ string (insertSubview).
-- E
···
On Mar 14, 2016, at 6:09 PM, Chris Lattner <clattner@apple.com> wrote:
On Mar 14, 2016, at 1:49 PM, Erica Sadun <erica@ericasadun.com <mailto:erica@ericasadun.com>> wrote:
On Mar 14, 2016, at 2:37 PM, Chris Lattner <clattner@apple.com <mailto:clattner@apple.com>> wrote:
If it is practical to get the module-relative path, I’d rather see us switch #file to produce *that*, and introduce a #fullPath that produces the current behavior. Rationale: we want to encourage deterministic and stable builds wherever possible, and including the full path to a source file breaks the ability to build in different directories (e.g. two different users’s homedirs) and get the same executable out.I'd like to know one way or another. My current understanding is that this is not produced as part of the build.
And, quite honestly, I'd sort of like to see better names. I stuck with file, line, column, and function because those were the current art.
Now that the identifiers are growing, relativeFilePath, fullFilePath, fileName, lineNumber (or fileLineNumber), fileColumn, and functionSignature (that's somehow compliant with the updated signatures proposal) seem more appropriate. The old "function" string just feels archaic and wrong.In this case, I don’t think that more is better. Having too many options and knobs is not good for anyone. Having #file produce the module-relative path (including the module name) serves all of the use-cases that I’m aware of, since you can further slice and dice it to get the base file name out.
What other use cases exist, and how important are they?
-Chris