> __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 < [email protected]> 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* :) >
