allMembers returns "this", but trying to get "this" or "__ctor" using getMember fails. Is there any way to get this method?

On Friday, 13 September 2013 at 09:12:53 UTC, simendsjo wrote:
> allMembers returns "this", but trying to get "this" or "__ctor" using getMember fails. Is there any way to get this method?

foreach (func; __traits(getOverloads, T, "__ctor"))
{
	...
}

On Friday, 13 September 2013 at 13:16:12 UTC, Gary Willoughby wrote:
> On Friday, 13 September 2013 at 09:12:53 UTC, simendsjo wrote:
>> allMembers returns "this", but trying to get "this" or "__ctor" using getMember fails. Is there any way to get this method?
>
> foreach (func; __traits(getOverloads, T, "__ctor"))
> {
> 	...
> }

Thanks.

Still a bit strange though.. "this" is always a member for classes, but if there's only an implicit ctor, only "this" exists, and getOverloads "__ctor" fails.

If there exists explicit ctors on the other hand, both "this" *and* "__ctor" exists.

On Friday, 13 September 2013 at 13:31:34 UTC, simendsjo wrote:
> On Friday, 13 September 2013 at 13:16:12 UTC, Gary Willoughby wrote:
>> On Friday, 13 September 2013 at 09:12:53 UTC, simendsjo wrote:
>>> allMembers returns "this", but trying to get "this" or "__ctor" using getMember fails. Is there any way to get this method?
>>
>> foreach (func; __traits(getOverloads, T, "__ctor"))
>> {
>> 	...
>> }
>
> Thanks.
>
> Still a bit strange though.. "this" is always a member for classes, but if there's only an implicit ctor, only "this" exists, and getOverloads "__ctor" fails.
>
> If there exists explicit ctors on the other hand, both "this" *and* "__ctor" exists.

A lot of the traits stuff is very confusing, i think a lot of it is still being finalised and in development. I'm working on a project using a lot of traits stuff and it's doing my head in. I wish there was better documentation. e.g. what is 'func' in the code above? i'm using it successfully but i've no idea what it is.

On Friday, 13 September 2013 at 14:02:15 UTC, Gary Willoughby wrote:
> On Friday, 13 September 2013 at 13:31:34 UTC, simendsjo wrote:
>> On Friday, 13 September 2013 at 13:16:12 UTC, Gary Willoughby wrote:
>>> On Friday, 13 September 2013 at 09:12:53 UTC, simendsjo wrote:
>>>> allMembers returns "this", but trying to get "this" or "__ctor" using getMember fails. Is there any way to get this method?
>>>
>>> foreach (func; __traits(getOverloads, T, "__ctor"))
>>> {
>>> 	...
>>> }
>>
>> Thanks.
>>
>> Still a bit strange though.. "this" is always a member for classes, but if there's only an implicit ctor, only "this" exists, and getOverloads "__ctor" fails.
>>
>> If there exists explicit ctors on the other hand, both "this" *and* "__ctor" exists.
>
> A lot of the traits stuff is very confusing, i think a lot of it is still being finalised and in development. I'm working on a project using a lot of traits stuff and it's doing my head in. I wish there was better documentation. e.g. what is 'func' in the code above? i'm using it successfully but i've no idea what it is.

I know what you mean. Have been using quite some __traits and is(), and I still have to look up the syntax for is() all the time, and experiment with both trying to find the edge-cases.

My biggest problem is that there's only one possible context pointer for templates and that often DMD is unable to use contexts even though they are mixed in at the call-site and really should be available...

On Fri, Sep 13, 2013 at 04:16:30PM +0200, simendsjo wrote:
> On Friday, 13 September 2013 at 14:02:15 UTC, Gary Willoughby wrote:
[...]
> >A lot of the traits stuff is very confusing, i think a lot of it is still being finalised and in development. I'm working on a project using a lot of traits stuff and it's doing my head in. I wish there was better documentation. e.g. what is 'func' in the code above? i'm using it successfully but i've no idea what it is.
> 
> I know what you mean. Have been using quite some __traits and is(),
> and I still have to look up the syntax for is() all the time, and
> experiment with both trying to find the edge-cases.
[...]

The syntax for is() is one gigantic mess. It does work, but it's not pretty. IIRC Walter admitted that it could do with some cleanup, but it's a bit too late now since too much code relies on its quirks.

As for __traits, I believe the intention was that it wasn't meant for end-user consumption, but for Phobos to be able to access compiler internals. As such, it only provides the bare minimum for Phobos to be able to work, so there are a lot of quirks and edge cases. I was quite dismayed yesterday to discover that "parameter type tuples" are actually different from the usual "type tuples", and don't even behave consistently with foreach (they masquerade as type tuples w.r.t. foreach, and there's weird special-casing for 1-element slices of them, e.g. for __traits(identifier...)). I don't know what's the rationale for this strange design, but it sure looks like it was just a quick hack to make Phobos work rather than anything carefully thought out.

Personally, I would just stick with the Phobos interfaces, and file bugs (or pull requests) if the existing interfaces aren't sufficient for your needs.


T

-- 
Let X be the set not defined by this sentence...

On Friday, 13 September 2013 at 15:16:36 UTC, H. S. Teoh wrote:
> On Fri, Sep 13, 2013 at 04:16:30PM +0200, simendsjo wrote:
>> On Friday, 13 September 2013 at 14:02:15 UTC, Gary Willoughby wrote:
> [...]
>> >A lot of the traits stuff is very confusing, i think a lot of it
>> >is still being finalised and in development. I'm working on a
>> >project using a lot of traits stuff and it's doing my head in. I
>> >wish there was better documentation. e.g. what is 'func' in the
>> >code above? i'm using it successfully but i've no idea what it is.
>> 
>> I know what you mean. Have been using quite some __traits and is(),
>> and I still have to look up the syntax for is() all the time, and
>> experiment with both trying to find the edge-cases.
> [...]
>
> The syntax for is() is one gigantic mess. It does work, but it's not
> pretty. IIRC Walter admitted that it could do with some cleanup, but
> it's a bit too late now since too much code relies on its quirks.
>
> As for __traits, I believe the intention was that it wasn't meant for
> end-user consumption, but for Phobos to be able to access compiler
> internals. As such, it only provides the bare minimum for Phobos to be
> able to work, so there are a lot of quirks and edge cases. I was quite
> dismayed yesterday to discover that "parameter type tuples" are actually
> different from the usual "type tuples", and don't even behave
> consistently with foreach (they masquerade as type tuples w.r.t.
> foreach, and there's weird special-casing for 1-element slices of them,
> e.g. for __traits(identifier...)). I don't know what's the rationale for
> this strange design, but it sure looks like it was just a quick hack to
> make Phobos work rather than anything carefully thought out.
>
> Personally, I would just stick with the Phobos interfaces, and file bugs
> (or pull requests) if the existing interfaces aren't sufficient for your
> needs.
>
>
> T

We should clean up this mess in 'is' and 'traits' and especially for tuples. IMO it's ok if it breaks code as long as it helps to write cleaner and tough code. This will also help D to gain more attention.
There is so many crap in D... We should really start to clean up as long as D2 is still a Beta.
And we should stop to transform it into something like C++ with transferring built-in features into the library (like scope or delete).

On Friday, 13 September 2013 at 15:27:42 UTC, Namespace wrote:
> On Friday, 13 September 2013 at 15:16:36 UTC, H. S. Teoh wrote:
>> On Fri, Sep 13, 2013 at 04:16:30PM +0200, simendsjo wrote:
>>> On Friday, 13 September 2013 at 14:02:15 UTC, Gary Willoughby wrote:
>> [...]
(...)
>>
>> The syntax for is() is one gigantic mess. It does work, but it's not
>> pretty. IIRC Walter admitted that it could do with some cleanup, but
>> it's a bit too late now since too much code relies on its quirks.
(...)

>
> We should clean up this mess in 'is' and 'traits' and especially for tuples. IMO it's ok if it breaks code as long as it helps to write cleaner and tough code. This will also help D to gain more attention.
> There is so many crap in D... We should really start to clean up as long as D2 is still a Beta.
> And we should stop to transform it into something like C++ with transferring built-in features into the library (like scope or delete).

D2 is in beta...?

I agree is() and __traits is quite messy, and I have quite some workarounds for various stuff in the combination of is() __traits(), alias, enum and templates - basically generic programming.

But I doubt many people here agree D2 is in beta and will allow breaking existing code in ways that changing the aforementioned features would do.

On Friday, 13 September 2013 at 22:10:02 UTC, simendsjo wrote:
> On Friday, 13 September 2013 at 15:27:42 UTC, Namespace wrote:
>> On Friday, 13 September 2013 at 15:16:36 UTC, H. S. Teoh wrote:
>>> On Fri, Sep 13, 2013 at 04:16:30PM +0200, simendsjo wrote:
>>>> On Friday, 13 September 2013 at 14:02:15 UTC, Gary Willoughby wrote:
>>> [...]
> (...)
>>>
>>> The syntax for is() is one gigantic mess. It does work, but it's not
>>> pretty. IIRC Walter admitted that it could do with some cleanup, but
>>> it's a bit too late now since too much code relies on its quirks.
> (...)
>
>>
>> We should clean up this mess in 'is' and 'traits' and especially for tuples. IMO it's ok if it breaks code as long as it helps to write cleaner and tough code. This will also help D to gain more attention.
>> There is so many crap in D... We should really start to clean up as long as D2 is still a Beta.
>> And we should stop to transform it into something like C++ with transferring built-in features into the library (like scope or delete).
>
> D2 is in beta...?
>
> I agree is() and __traits is quite messy, and I have quite some workarounds for various stuff in the combination of is() __traits(), alias, enum and templates - basically generic programming.
>
> But I doubt many people here agree D2 is in beta and will allow breaking existing code in ways that changing the aforementioned features would do.

Not...?
It's far away from final. o.O
If D2 is final I tend to leave this scene... It more broken than C++ ever was.

On 2013-09-14 00:10, simendsjo wrote:

> But I doubt many people here agree D2 is in beta and will allow breaking
> existing code in ways that changing the aforementioned features would do.

DMD breaks code in every single release. All 2.05x and 2.06x releases have caused code breakage for DWT in some way or another.

-- 
/Jacob Carlborg