toHash => pure, nothrow, const, @safe

[Alex Rønne Petersen]

On 12-03-2012 18:38, Jonathan M Davis wrote:
> On Monday, March 12, 2012 14:23:28 Alex Rønne Petersen wrote:
>> On 12-03-2012 14:16, deadalnix wrote:
>>> Le 12/03/2012 13:51, Alex Rønne Petersen a écrit :
>>>> On 12-03-2012 10:40, Walter Bright wrote:
>>>>> On 3/12/2012 1:08 AM, Martin Nowak wrote:
>>>>>> What's wrong with auto-inference. Inferred attributes are only
>>>>>> strengthening
>>>>>> guarantees.
>>>>>
>>>>> Auto-inference is currently done for lambdas and template functions -
>>>>> why? - because the function's implementation is guaranteed to be visible
>>>>> to the compiler. For other functions, not so, and so the attributes must
>>>>> be part of the function signature.
>>>>
>>>> Isn't auto-inference for templates a Bad Thing (TM) since it may give
>>>> API guarantees that you can end up silently breaking?
>>>
>>> As long as you can explicitly specify that too, and that you get a
>>> compile time error when you fail to provide what is explicitly stated,
>>> this isn't a problem.
>>
>> But people might be relying on your API that just so happens to be pure,
>> but then suddenly isn't!
>
> True, but without out, pure, @safe, and nothrow are essentially useless with
> templates, because far too many templates depend on their arguments for
> whether they can be pure, @safe, and/or nothrow or not. It's attribute
> inference for templates that made it possible to use something stuff like
> std.range and std.algorithm in pure functions. Without that, it couldn't be
> done (at least not without some nasty casting). Attribute inference is
> necessary for templates.
>
> Now, that _does_ introduce the possibility of a template being to be pure and
> then not being able to be pure thanks to a change that's made to it or
> something that it uses, and that makes impossible for any code using it to be
> pure. CTFE has the same problem. It's fairly easy to have a function which is
> CTFEable cease to be CTFEable thanks to a change to it, and no one notices.
> We've had issues with this in the past.

That could be solved with a @ctfe attribute or something, no? Like, if 
the function has @ctfe, go through all possible CTFE paths (excluding 
!__ctfe paths of course) and make sure they are CTFEable.

>
> In both cases, I believe that the best solution that we have is to unit test
> stuff to show that it _can_ be pure, @safe, nothrow, and/or CTFEable if the
> arguments support it, and then those tests can guarantee that it stays that
> way in spite of any code changes, since they'll fail if the changes break
> that.
>
> - Jonathan M Davis


-- 
- Alex