>Remember, we can always add this. But we cannot remove it once added.

Well this depends on your definition/requirements of ABI/API stability. Any change will break the ABI, removing fields later will break the API as well, indeed. However, if we can't convince you now to add these fields I don't see how we could convince you at any later point.

> Fair enough - please reproduce the explanation here or provide a link.

Unfortunately github looses many comments when rebasing, so this was lost somewhere.
But the reason is being able to run tests selectively. The only way to identify an unnamed test is file + line.
Then when fixing a bug detected by a unittest you can simply run this single test again and again. It's also very useful if you have segfaulting unittests and you want some way to run another test.

And you can do this without recompiling. When porting to ARM I often wished I could run some tests selectively. Running all tests takes ages and there's no need to run tests again and again if you already know they succeed. Then you have segfaulting tests which should not run at all if you want to debug some other test first.

It's also great for IDE integration: Simply right click on a unittest, select run to run the single test (useful when writing a new test). Run all tests in a module, or match success/fail/disabled status to the actual source code. (For example an IDE could present all unittests in a treeview, showing red/yeellow/green icons depending on the test result)

> Forgot to add that the line number is also embedded in the default unittest identifier, and the file is discernible from the ModuleInfo.

The line number is only in the mangled name, not the 'name' unittest info field. We could change this, but then we add the same information which we could add as a simple uint in a string instead, potentially requiring more space and making it more difficult to use.

And, as already mentioned before, the file cannot be determined from ModuleInfo because template instances go to the ModuleInfo where they are used, but you want the declaration file/line. This is not an artificial problem, importing std.stdio already imports two such tests.

>File & line go into asserts because it isn't usual to ship an executable with symbolic debug 
>info in it. Unit testing, however, is different.

As mentioned above you sometimes need the information before running a test. Debug info won't help here. (Unless you're suggesting we implement parsers for every known debug information, then look up the function pointer in that debug info).

This is also about convenience. Even if you can find the location by looking at the debug info, it's way more complicated than a field in unittest info. There's a huge difference between running ```./unittest``` and getting ```FAILED: FILE:LINE``` and setting a breakpoint on some assert function (how many people even know where to set the breakpoint?) and running a program through a debugger. Inspecting the stack traces is not much better. You first need a valid stacktrace implementation for your architecture. Just a reminder: druntime still can't find function names by dwarf debug info, it uses the ```--export-dynamic``` hack.

And for tools like IDEs it's much easier to use file/line information from unittest info to display a failed test than running a debugger and parsing stack traces.