all in native Swift without having to bridge to `NSString` or call `lastPathComponent`.
A bit of water has gone under the #identifier bridge since SE-0028, specifically a general embrace of
lowerCamelCase identifiers and unambiguous names. I think `#fileName` conforms to that
philosophy.
(One might want to rename `#line` to `#lineNumber`, `#file` to `#filePath`, and `#column`
to `#fileColumn` but those lie outside the scope of this pitch.)
It should be OK to have multiple files with the same name in the
project. For example, in the Swift compiler we have Decl.cpp in both
Clang and Swift. It is important to distinguish these in the
assertion messages.
Thus, I'd suggest to consider instead passing the project directory to
the compiler, so that the compiler can provide a file name relative to
the project root.
You can even go as far as replacing the project root with the
project-version string. For example:
#relativeFileName could expand to
"<MyStringExtras-1.0>/String+KnuthMorrisPrattSearch.swift"
Dmitri
···
On Sat, Mar 12, 2016 at 7:04 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:
Here is a small one as pitches go, but I think it embraces the spirit of the
Groff (http://bit.ly/1pn47Yr\).
Of all the possible expansions brought up in the SE-0028 discussion on
modernizing
debug identifiers, I would get a lot of use out of `#fileName` for my debug
logging.
A simple websearch for `__FILE__ lastPathComponent` yields page after page
of results
across both Swift and Objective-C.
My idea is that a `#fileName` debug identifier would return the file name
and not the entire
path for logging.
Agreed that name overlap is possible. I tend to use a lot of shared code
with "add reference" vs "add file" and relative-to-project-root actually
ends up longer that way than just absolute path.
-- Erica
···
On Mar 12, 2016, at 8:27 PM, Dmitri Gribenko <gribozavr@gmail.com> wrote:
It should be OK to have multiple files with the same name in the
project. For example, in the Swift compiler we have Decl.cpp in both
Clang and Swift. It is important to distinguish these in the
assertion messages.
Thus, I'd suggest to consider instead passing the project directory to
the compiler, so that the compiler can provide a file name relative to
the project root.
Here is a small one as pitches go, but I think it embraces the spirit of the
Groff (http://bit.ly/1pn47Yr\).
Of all the possible expansions brought up in the SE-0028 discussion on
modernizing
debug identifiers, I would get a lot of use out of `#fileName` for my debug
logging.
A simple websearch for `__FILE__ lastPathComponent` yields page after page
of results
across both Swift and Objective-C.
My idea is that a `#fileName` debug identifier would return the file name
and not the entire
path for logging.
It should be OK to have multiple files with the same name in the
project. For example, in the Swift compiler we have Decl.cpp in both
Clang and Swift. It is important to distinguish these in the
assertion messages.
Thus, I'd suggest to consider instead passing the project directory to
the compiler, so that the compiler can provide a file name relative to
the project root.
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.
-Chris
···
On Mar 12, 2016, at 7:27 PM, Dmitri Gribenko via swift-evolution <swift-evolution@swift.org> wrote:
On Sat, Mar 12, 2016 at 7:04 PM, Erica Sadun via swift-evolution > <swift-evolution@swift.org> wrote:
You can even go as far as replacing the project root with the
project-version string. For example:
#relativeFileName could expand to
"<MyStringExtras-1.0>/String+KnuthMorrisPrattSearch.swift"
TLDR: a path relative to the project would be nice.
I agree an absolute path is often too much.
I don't have much file name overlap, but would it happen I reckon I would be glad to be able to differentiate them.
Pierre
···
Le 13 mars 2016 à 05:07, Erica Sadun via swift-evolution <swift-evolution@swift.org> a écrit :
On Mar 12, 2016, at 8:27 PM, Dmitri Gribenko <gribozavr@gmail.com> wrote:
It should be OK to have multiple files with the same name in the
project. For example, in the Swift compiler we have Decl.cpp in both
Clang and Swift. It is important to distinguish these in the
assertion messages.
Thus, I'd suggest to consider instead passing the project directory to
the compiler, so that the compiler can provide a file name relative to
the project root.
Agreed that name overlap is possible. I tend to use a lot of shared code
with "add reference" vs "add file" and relative-to-project-root actually
ends up longer that way than just absolute path.
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.
-- E
···
On Mar 14, 2016, at 2:37 PM, Chris Lattner <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.
Agreed. It’s really not useful for anyone to see `/Users/radex/Documents/Projects/MillionDollarAppIdea/` when logging errors or… anything really.
I think a project-relative path should just be the new #file. I’m not even sure the full absolute path is necessary — but if it is, I’d rename it.
— Radek
···
On 13 Mar 2016, at 18:12, Pierre Monod-Broca via swift-evolution <swift-evolution@swift.org> wrote:
TLDR: a path relative to the project would be nice.
I agree an absolute path is often too much.
I don't have much file name overlap, but would it happen I reckon I would be glad to be able to differentiate them.
Pierre
Le 13 mars 2016 à 05:07, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit :
On Mar 12, 2016, at 8:27 PM, Dmitri Gribenko <gribozavr@gmail.com <mailto:gribozavr@gmail.com>> wrote:
It should be OK to have multiple files with the same name in the
project. For example, in the Swift compiler we have Decl.cpp in both
Clang and Swift. It is important to distinguish these in the
assertion messages.
Thus, I'd suggest to consider instead passing the project directory to
the compiler, so that the compiler can provide a file name relative to
the project root.
Agreed that name overlap is possible. I tend to use a lot of shared code
with "add reference" vs "add file" and relative-to-project-root actually
ends up longer that way than just absolute path.
Just wanted to remind everyone that we control the whole stack, the
swift compiler, the package manager etc. If something needs to change
in the tooling to pass extra arguments to the compiler to support this
feature, we can coordinate across all projects and make it happen.
Let's figure out an end state that we like, and that is feasible to
implement.
Dmitri
···
On Mon, Mar 14, 2016 at 1:49 PM, Erica Sadun <erica@ericasadun.com> wrote:
On Mar 14, 2016, at 2:37 PM, Chris Lattner <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.
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
···
On Mar 14, 2016, at 1:49 PM, Erica Sadun <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.
I think the biggest part of the problem is that Xcode has no option for building the project with relative file paths.
If file paths were relative (and `$PWD` were set to the project root—like it indeed is!) then `#file` would be the relative name. Actually, you can try it out, just give `swiftc` a roll yourself!
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?