Artur Skawina:

> Keep in mind that D's offsetof is flawed - if the object does not contain the requested member, but implicitly converts to another one that does have such field then the expression
> compiles, but yields a bogus value. Eg
>
>    struct S { int a, b, c; S2 s2; alias s2 this; }
>    struct S2 { int d, e; }
>    static assert(S.e.offsetof==4); // Oops.

Is this in Bugzilla?

Bye,
bearophile

On Tuesday, 6 May 2014 at 14:25:01 UTC, Artur Skawina via Digitalmars-d-learn wrote:
> I'm not sure why you'd want to wrap the .offsetof expression in
> a template, but it can easily be done like this:
>
>    enum offsetOf(alias A, string S) = mixin("A."~S~".offsetof");

Great, that's even shorter.

Somehow I was fixated on converting the symbol to a string first, but of course the name is directly available in the mixin:

    enum offsetof(alias typenfield) = mixin("typenfield.offsetof");

On 05/06/14 16:45, via Digitalmars-d-learn wrote:
> On Tuesday, 6 May 2014 at 14:25:01 UTC, Artur Skawina via Digitalmars-d-learn wrote:
>> I'm not sure why you'd want to wrap the .offsetof expression in a template, but it can easily be done like this:
>>
>>    enum offsetOf(alias A, string S) = mixin("A."~S~".offsetof");
> 
> Great, that's even shorter.
> 
> Somehow I was fixated on converting the symbol to a string first, but of course the name is directly available in the mixin:
> 
>     enum offsetof(alias typenfield) = mixin("typenfield.offsetof");

I didn't realize that worked, but it does. So...

   enum offsetOf(alias A) = A.offsetof;


But I have no idea why anybody would want to wrap this trivial expression like that.

And, I have no idea if the, hmm, /unconventional/ D offsetof semantics are in the bugzilla. It's not really a "bug", but a design mistake...

artur

Artur Skawina:

> And, I have no idea if the, hmm, /unconventional/ D offsetof semantics
> are in the bugzilla. It's not really a "bug", but a design mistake...

Design mistakes are valid bugzilla entries. At worst the bad behavior could be documented. But often it's possible to fix the design too, with a small breaking change.

Bye,
bearophile

Artur Skawina:

> But I have no idea why anybody would want to wrap this trivial
> expression like that.
>
> And, I have no idea if the, hmm, /unconventional/ D offsetof semantics
> are in the bugzilla. It's not really a "bug", but a design mistake...

https://issues.dlang.org/show_bug.cgi?id=12714

Bye,
bearophile

On Tuesday, 6 May 2014 at 15:13:41 UTC, Artur Skawina via Digitalmars-d-learn wrote:
> On 05/06/14 16:45, via Digitalmars-d-learn wrote:
>> On Tuesday, 6 May 2014 at 14:25:01 UTC, Artur Skawina via Digitalmars-d-learn wrote:
>>> I'm not sure why you'd want to wrap the .offsetof expression in
>>> a template, but it can easily be done like this:
>>>
>>>    enum offsetOf(alias A, string S) = mixin("A."~S~".offsetof");
>> 
>> Great, that's even shorter.
>> 
>> Somehow I was fixated on converting the symbol to a string first, but of course the name is directly available in the mixin:
>> 
>>     enum offsetof(alias typenfield) = mixin("typenfield.offsetof");
>
> I didn't realize that worked, but it does. So...
>
>    enum offsetOf(alias A) = A.offsetof;
>
>
> But I have no idea why anybody would want to wrap this trivial
> expression like that.
>
> And, I have no idea if the, hmm, /unconventional/ D offsetof semantics
> are in the bugzilla. It's not really a "bug", but a design mistake...
>
> artur

just out of curiousity, why an alias is used there?