<div dir="ltr"><span style="font-size:12.8px">> __DIR__ + __FILE__ is not equivalent to __FILE_FULL_PATH__.</span><div><br></div><div>Like is said, it's equivalent to <span style="font-size:12.8px">buildPath(__</span><wbr style="font-size:12.8px"><span style="font-size:12.8px">DIR__, </span><span style="font-size:12.8px">__FILE_FULL_PATH__</span><span style="font-size:12.8px">). This works whether </span><span style="font-size:12.8px">__FILE_FULL_PATH__ is absolute file or not (see buildPath docs)</span></div><div><br style="font-size:12.8px"><div><span style="font-size:12.8px">> </span><span style="font-size:12.8px">__FILE_FULL_PATH__ would be equivalent to __DIR__ + __FILE__.baseName.</span></div><div><br></div>not true. <span style="font-size:12.8px">__FILE__ can be: foo/bar/baz.d, </span><span style="font-size:12.8px">__DIR__ could be /path/to/import/ (and the file being compiled is under </span><span style="font-size:12.8px">/path/to/import/</span><span style="font-size:12.8px">foo/bar/baz.d</span><span style="font-size:12.8px">). </span><span style="font-size:12.8px">__DIR__ + __FILE__.baseName would return wrong answer.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">> </span><span style="font-size:12.8px">__FILE_FULL_PATH__ makes other scenarios easier</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Please name a single one.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">__FILE_FULL_PATH__ should be deprecated if __DIR__ is added. It has all the advantages I listed in original post.</span><span style="font-size:12.8px"><br></span></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 9, 2017 at 10:11 AM, Jonathan Marler via Digitalmars-d <span dir="ltr"><<a href="mailto:digitalmars-d@puremagic.com" target="_blank">digitalmars-d@puremagic.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Monday, 9 January 2017 at 17:47:27 UTC, Timothee Cour wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* smaller binaries (no need to store redundant path information in __FILE_FULL_PATH__ when __DIR__ + __FILE__ is enough)<br>
</blockquote>
<br></span>
__DIR__ + __FILE__ is not equivalent to __FILE_FULL_PATH__.<br>
<br>
__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.<br>
<br>
__FILE_FULL_PATH__ would be equivalent to __DIR__ + __FILE__.baseName.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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* :)<br>
</blockquote></div><br></div>