On Mon, Nov 23, 2015 at 3:27 PM, Rafael Espíndola
<rafael.espindola at gmail.com> wrote:> 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?
I would be okay with that. The caller should never really care about
whether a directory is system-wide or user-specific anyway, at least
in terms of temp and cache.
Thanks!
~Aaron