On Tue, 13 Mar 2012 12:03:22 -0400, Alex Rønne Petersen <xtzgzorex@gmail.com> wrote:

> Yes, and in some cases, it doesn't even work right; i.e. you can declare certain opCmp and opEquals signatures that work fine for ==, >, <, etc but don't get emitted to the TypeInfo metadata, and vice versa. It's a mess.

See my post in this thread.  It fixes this problem.

-Steve

On Mon, 12 Mar 2012 22:06:51 -0400, Walter Bright <newshound2@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.

-Steve

On Tue, 13 Mar 2012 19:23:25 -0400, Walter Bright <newshound2@digitalmars.com> wrote:

> On 3/13/2012 4:15 AM, Don Clugston wrote:
>> On 13/03/12 03:05, Walter Bright wrote:
>>> On 3/12/2012 6:15 PM, Stewart Gordon wrote:
>>>> And what about toString?
>>>
>>> Good question. What do you suggest?
>>
>> Why can't we just kill that abomination?
>
> Break a lot of existing code?

I'm unaware of much code that uses TypeInfo.xtostring to print anything.  write[f][ln] doesn't, and I don't think std.conv.to does either.

In other words, killing the "specialness" of toString doesn't mean killing toString methods in all structs.  What this does is allow us to not worry about what you annotate your toString methods with, it just becomes a regular method.

-Steve

On 14.03.2012 16:11, Steven Schveighoffer wrote:
> On Mon, 12 Mar 2012 22:06:51 -0400, Walter Bright
> <newshound2@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

> 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.
>
Why would you want to add explicit annotation for implicit TypeInfo_Struct methods?
I think @type is a very interesting idea if combined with a string->method lookup in
TypeInfo_Struct, but this wouldn't allow for static type checking.
If you wanted static type checking then @type could probably refer to Interfaces.

On Wed, 14 Mar 2012 09:27:08 -0400, Martin Nowak <dawg@dawgfoto.de> wrote:

>> 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.
>>
> Why would you want to add explicit annotation for implicit TypeInfo_Struct methods?

Because right now, it's a guessing game of whether you wanted an operation to be part of the typeinfo's interface.  And many times, the compiler guesses wrong.  I've seen countless posts on d.learn saying "why won't AA's call my opEquals or opHash function?"

With explicit annotation, you have instructed the compiler "I expect this to be in TypeInfo," so it can take the appropriate actions if it doesn't match.

> I think @type is a very interesting idea if combined with a string->method lookup in
> TypeInfo_Struct, but this wouldn't allow for static type checking.

Yes it would.  It has access to TypeInfo_Struct in object.di, so it can figure out what the signature should be.

-Steve