llvm dev - Nov 2015 - [Path] RFC: Known directories

> We appear to use both system_temp_directory(true) and
> system_temp_directory(false) in ways that seem like they could matter.
> For instance, modules uses a temp directory that does not get erased
> on reboot, possibly for performance reasons. Do we gain something from
> deprecating system_temp_directory()?
I have a small preference for having the distinction in the name:

*_temp_* -> something that is one use and potentially deleted often
*_cache_* -> something we would like to save (modules for example).

So what we gain is clarity over a bool parameter.

Cheers,
Rafael

On Mon, Nov 23, 2015 at 3:07 PM, Rafael Espíndola
<rafael.espindola at gmail.com> wrote:
>> We appear to use both system_temp_directory(true) and
>> system_temp_directory(false) in ways that seem like they could matter.
>> For instance, modules uses a temp directory that does not get erased
>> on reboot, possibly for performance reasons. Do we gain something from
>> deprecating system_temp_directory()?
>
> I have a small preference for having the distinction in the name:
>
> *_temp_* -> something that is one use and potentially deleted often
> *_cache_* -> something we would like to save (modules for example).
>
> So what we gain is clarity over a bool parameter.
We already have user_cache_directory, and it means something different
than system_temp_directory(false) today.

~Aaron

On 23 November 2015 at 15:11, Aaron Ballman <aaron.ballman at gmail.com>
wrote:
> On Mon, Nov 23, 2015 at 3:07 PM, Rafael Espíndola
> <rafael.espindola at gmail.com> wrote:
>>> We appear to use both system_temp_directory(true) and
>>> system_temp_directory(false) in ways that seem like they could
matter.
>>> For instance, modules uses a temp directory that does not get
erased
>>> on reboot, possibly for performance reasons. Do we gain something
from
>>> deprecating system_temp_directory()?
>>
>> I have a small preference for having the distinction in the name:
>>
>> *_temp_* -> something that is one use and potentially deleted often
>> *_cache_* -> something we would like to save (modules for example).
>>
>> So what we gain is clarity over a bool parameter.
>
> We already have user_cache_directory, and it means something different
> than system_temp_directory(false) today.
It was just added. My understanding was that the intention was for it
to have the correct semantics for things like clang modules. Maybe we
should

* Rename user_cache_directory to just cache_directory
* Adjust it semantics so that it can be used in cases that currently
uses system_temp_directory(false).
* Replace remaining uses with temp_directory.

That is, in the end we would have only

* temp_directory
* cache_directory
* home_directory

What do you think?

Cheers,
Rafael