On Mon, 12 Mar 2012 22:06:51 -0400, Walter Bright
<[email protected]> 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.
-Steve
