On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
> [ ... ]
Hi Guys,
I wanted to give a short status update again.
No new features;
But a few things have changed under the hood.
I am currently cleaning up code to get ready for a first publicized preview build.

After || und && are implemented (which currently still give me an unreasonable amount of trouble), the preview will go life :)

Cheers,
Stefan

Hi!

Is it hard to implement some way to access symbol from UDA constructor of symbol?

```
class uda
{
    this()
    {
         // Iterate by Foo members
        foreach (member; __traits(allMembers, __SYMBOL__))
            ...
    }
}


@uda
struct Foo
{

}

```

On Saturday, 8 April 2017 at 08:50:27 UTC, crimaniak wrote:
> Hi!
>
> Is it hard to implement some way to access symbol from UDA constructor of symbol?
>
> ```
> class uda
> {
>     this()
>     {
>          // Iterate by Foo members
>         foreach (member; __traits(allMembers, __SYMBOL__))
>             ...
>     }
> }
>
>
> @uda
> struct Foo
> {
>
> }
>
> ```

This is a question for D.Learn.
please post there.
Also the question is to terse, I do not know what you are asking.

On 08/04/2017 10:14 AM, Stefan Koch wrote:
> On Saturday, 8 April 2017 at 08:50:27 UTC, crimaniak wrote:
>> Hi!
>>
>> Is it hard to implement some way to access symbol from UDA constructor
>> of symbol?
>>
>> ```
>> class uda
>> {
>>     this()
>>     {
>>          // Iterate by Foo members
>>         foreach (member; __traits(allMembers, __SYMBOL__))
>>             ...
>>     }
>> }
>>
>>
>> @uda
>> struct Foo
>> {
>>
>> }
>>
>> ```
>
> This is a question for D.Learn.
> please post there.
> Also the question is to terse, I do not know what you are asking.

Nope, not valid for D.learn as it is not currently possible.

On Saturday, 8 April 2017 at 09:19:03 UTC, rikki cattermole wrote:
>
> Nope, not valid for D.learn as it is not currently possible.

perfectly valid in D.learn.
You could have given the answer that is it not possible there.

On Saturday, 8 April 2017 at 09:14:17 UTC, Stefan Koch wrote:
> This is a question for D.Learn.
> please post there.
Yes, I did it already and know, it is not possible for now: https://forum.dlang.org/post/crkxlbtfhsplxfilakrk@forum.dlang.org

This is exact reason why I asked, how hard _to implement_ it. I asked you, because UDF constructor executed in CTFE, and you can give the most competent answer, because you are working on it.

> Also the question is to terse, I do not know what you are asking.

  How hard to implement something like special keyword __SYMBOL__, which will be alias for Foo (or string with fully qualified name of Foo) in example in my initial letter, in the scope of udf constructor.

On Saturday, 8 April 2017 at 19:03:52 UTC, crimaniak wrote:
> On Saturday, 8 April 2017 at 09:14:17 UTC, Stefan Koch wrote:
>> This is a question for D.Learn.
>> please post there.
> Yes, I did it already and know, it is not possible for now: https://forum.dlang.org/post/crkxlbtfhsplxfilakrk@forum.dlang.org
>
> This is exact reason why I asked, how hard _to implement_ it. I asked you, because UDF constructor executed in CTFE, and you can give the most competent answer, because you are working on it.
>
>> Also the question is to terse, I do not know what you are asking.
>
>   How hard to implement something like special keyword __SYMBOL__, which will be alias for Foo (or string with fully qualified name of Foo) in example in my initial letter, in the scope of udf constructor.

This is not related to the ctfe subsystem.

Therefore take my answer with a grain of salt.
I assume that what you want will quite expensive in terms of compiler performance.
Also it would require a language change.
A facility as you want it would need to modify the constructor behind the scenes, either by adding a hidden template parameter to the constructor.
I general I would be weary about adding this facility.
Though right now I cannot see any wired corner-cases, I think that you are going to run into trouble with this.
Particularly when forward-references are involved.

On Sunday, 9 April 2017 at 00:25:45 UTC, Stefan Koch wrote:
...
> I assume that what you want will quite expensive in terms of compiler performance.
...
Thanks for your answer!

On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
> [ ... ]

Hi Guys :)

I am currently fixing a bug involving complex members of structs
(where complex means (slice, struct, array or pointer))
I did expect them to be broken ...
but not to be _that_ broken :)

struct S
{
    uint[] slice;
}

uint fn()
{
  S s;
  s.slice.length = 12;
  return cast(uint)s.slice.length;
}

static assert(fn() == 12);
This code will not work because s.slice has no elementType :)
(which does not mean it has the s.slice[0] has the type void)
newCTFE literally looses the type information somewhere.

And people wonder why I don't like mondays :)

On Monday, 10 April 2017 at 20:49:58 UTC, Stefan Koch wrote:
> On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
>> [ ... ]
>
> Hi Guys :)
>
> I am currently fixing a bug involving complex members of structs
> (where complex means (slice, struct, array or pointer))
> I did expect them to be broken ...
> but not to be _that_ broken :)
>
> struct S
> {
>     uint[] slice;
> }
>
> uint fn()
> {
>   S s;
>   s.slice.length = 12;
>   return cast(uint)s.slice.length;
> }
>
> static assert(fn() == 12);
> This code will not work because s.slice has no elementType :)
> (which does not mean it has the s.slice[0] has the type void)
> newCTFE literally looses the type information somewhere.
>
> And people wonder why I don't like mondays :)

I found out that slice was never allocated :)
This is an orthogonal problem, but it's fixed now.

The problem from the above post still remains.
And I still don't know why it happens.