__DIR__ trait (return getcwd at compile time), replacing __FILE_FULL_PATH__

[Jonathan Marler via Digitalmars-d]

On Monday, 9 January 2017 at 17:47:27 UTC, Timothee Cour wrote:
> * smaller binaries (no need to store redundant path information 
> in __FILE_FULL_PATH__ when __DIR__ + __FILE__ is enough)

__DIR__ + __FILE__ is not equivalent to __FILE_FULL_PATH__.

__FILE__ really has no restriction, it could be an absolute 
filename itself, or it could be a relative path and the filename, 
or it could be just the filename by itself.

__FILE_FULL_PATH__ would be equivalent to __DIR__ + 
__FILE__.baseName.

I personally would be OK with adding __DIR__ to the language.  It 
makes some things easier, but __FILE_FULL_PATH__ makes other 
scenarios easier.  However, I don't think you're going to 
convince the current maintainers to add it.  It requires adding 
to the language and implementing the functionality in the 
compiler, which means you need a very good reason.

When __FILE_FULL_PATH__ was initially added, I argued there was a 
very good reason for it because the functionality was nonexistent 
in the language.  There was not way to get this information.  
However, now that we have __FILE_FULL_PATH__, you can easily get 
__DIR__ by using __FILE_FULL_PATH__.dirName.  Sure it would be 
more convenient to have  __DIR__ in some cases, but I don't think 
you're going to convince anyone this convenience is worth 
changing the language and all the compilers.

So to summarize, I agree it's a good idea, but brace yourself 
because I don't think people are going to welcome this idea with 
*open arms* :)