View mode: basic / threaded / horizontal-split · Log in · Help
March 14, 2012
Re: toHash => pure, nothrow, const, @safe
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
March 14, 2012
Re: toHash => pure, nothrow, const, @safe
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
March 14, 2012
Re: toHash => pure, nothrow, const, @safe
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
March 14, 2012
Re: toHash => pure, nothrow, const, @safe
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
March 14, 2012
Re: toHash => pure, nothrow, const, @safe
> 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.
March 14, 2012
Re: toHash => pure, nothrow, const, @safe
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
Next ›   Last »
5 6 7 8 9
Top | Discussion index | About this forum | D home