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

[Jonathan Marler via Digitalmars-d]

On Monday, 9 January 2017 at 21:59:04 UTC, Timothee Cour wrote:
>> __DIR__ + __FILE__ is not equivalent to __FILE_FULL_PATH__.
>
> Like is said, it's equivalent to buildPath(__DIR__, 
> __FILE_FULL_PATH__).
> This works whether __FILE_FULL_PATH__ is absolute file or not 
> (see
> buildPath docs)
>
>> __FILE_FULL_PATH__ would be equivalent to __DIR__ + 
>> __FILE__.baseName.
>
> not true. __FILE__ can be: foo/bar/baz.d, __DIR__ could be 
> /path/to/import/ (and the file being compiled is under 
> /path/to/import/foo/bar/baz.d). __DIR__ + __FILE__.baseName 
> would return wrong answer.
>
>> __FILE_FULL_PATH__ makes other scenarios easier
>
> Please name a single one.
>
>
> __FILE_FULL_PATH__ should be deprecated if __DIR__ is added. It 
> has all the advantages I listed in original post.
>
>
> On Mon, Jan 9, 2017 at 10:11 AM, Jonathan Marler via 
> Digitalmars-d < digitalmars-d at puremagic.com> wrote:
>
>> 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* :)

Ah I see I misunderstood your definition of __DIR__.  I thought 
it mean "The absolute path to the current file", but you state it 
actually meant "the absolute path of the current directory".

I also see now that your previous comments about calculating 
__FILE_FULL_PATH__ using buildPath(__DIR__, __FILE__) don't 
actually work.  I believe where you went wrong was assuming that 
the __FILE__ macro resolves to a filename that is always relative 
to the current directory, but this isn't the case.  The __FILE__ 
macro could resolve to an absolute path, or a relative path to an 
import directory (different than the current directory) or even 
just a filename with no path.  Furthermore, the language 
definition of the __FILE__ macro does not specify what kind of 
path it uses, so even if you figure out all the cases for DMD, 
they are subject to change and the other compilers are free to 
have their own implementation as well.

That being said, if you defined __DIR__ to mean "The path to the 
directory that contains __FILE__", then your previous comments 
would hold true.  In other words, if you defined __DIR__ as:

buildPath(__DIR__, __FILE__) == __FILE_FULL_PATH__

So now I hope we are on the same page.  That being said, my 
previous comments about having a good reason to change the 
language and all the compilers still apply.  I don't really see 
any big advantages to this.  This would make some use cases 
easier but other not so easy.  If your program wants the full 
path to the source file:

Using __DIR__ macro:             buildPath(__DIR__, __FILE__)
Using __FILE_FULL_PATH__ macro:  __FILE_FULL_PATH__

If you wanted the containing directory of the file, you would do 
this:

Using __DIR__ macro:             buildPath(__DIR__, 
__FILE__.dirName)
Using __FILE_FULL_PATH__ macro:  __FILE_FULL_PATH__.dirName

I suppose I don't really see a reason to ever want the value of 
the __DIR__ macro, but you could calculate it from __FILE__ and 
__FILE_FULL_PATH__.   The reason for not wanting the value of the 
__DIR__ macro is because of what I said before.  It doesn't have 
a strict definition, it can change between compilers, and really 
doesn't provide any useful information.  In my experience, the 
usefull piece that programmers will want will be the path/file to 
the source file.  The __DIR__ will just be an arbitrary directory 
that depends on the compiler implementation.