toHash => pure, nothrow, const, @safe

[Dmitry Olshansky]

On 14.03.2012 16:11, Steven Schveighoffer wrote:
> On Mon, 12 Mar 2012 22:06:51 -0400, Walter Bright
> <newshound2 at digitalmars.com> wrote:
>
>> On 3/12/2012 6:40 PM, H. S. Teoh wrote:
>>> And I'm not talking about doing just toHash, or just toString either.
>>> Any of these functions have complex interdependencies with each other,
>>> so it's either fix them ALL, or not at all.
>>
>> Yup. It also seems very hard to figure out a transitional path to it.
>
> It seems most people have ignored my post in this thread, so I'll say it
> again:
>
> What about an annotation (I suggested @type, it could be anything, but
> I'll use that as my strawman) that says to the compiler "this is part of
> the TypeInfo_Struct interface."
>
> In essence, when @type is encountered the compiler looks at
> TypeInfo_Struct (in object.di) for the equivalent xfuncname. Then uses
> the attributes of that function pointer (and also the parameter
> types/count) to compile the given method.
>
> It does two things:
>
> 1. It provides an indicator a user can use when he *wants* to include
> that function as part of the typeinfo. Right now, you have to guess, and
> pray to the compiler gods that your function signature is deemed worthy.
> 2. It takes all sorts of burden off the compiler to know which functions
> are "special", and to make assumptions about them.
>
> We can implement it now *without* making those function pointers
> pure/safe/nothrow/whatever, and people can then experiment with changing
> it without having to muck with the compiler.
>
> As a bonus, it also allows people to experiment with adding more
> interface methods to structs without having to muck with the compiler.
>
> The only drawback is what to do with existing code that *doesn't* have
> @type on it's functions that go into TypeInfo_Struct. There are ways to
> handle this. My suggestion is to simply treat the current methods as
> special and assume @type is on those methods. But I would suggest
> removing that "hack" in the future, with some way to easily tell you
> where you need to put @type annotations.
>

For one, I'm sold on it. And the proposed magic hack can work right now, 
then it'll just get deprecated in favor of explicit @type.


-- 
Dmitry Olshansky