On Monday, 12 February 2018 at 08:51:14 UTC, Simen Kjærås wrote:
> I agree that'd be nice. Sadly, it's not a reasonable expectation. :(

:)

> A more extreme example: You have a compiled library, and some .di (header) files. In one of those files is this code:
>
> struct S {
>     static int[] arr;
>     void foo();
> }
>
> Now how should Typedef go about making foo() do the right thing? Even with compiler support, this is impossible - the source of S.foo is simply not available, and it doesn't take the address of the static data as a parameter anywhere.
>
> --
>   Simen

But isn't foo scoped somehow?
I mean, if foo is part of a type, then either you have to write s.foo, or S.foo. And if the address of a static belongs to a type, shouldn't this resolve the ambiguities?

On Monday, 12 February 2018 at 09:10:52 UTC, Alex wrote:

>> A more extreme example: You have a compiled library, and some .di (header) files. In one of those files is this code:
>>
>> struct S {
>>     static int[] arr;
>>     void foo();
>> }
>>
>> Now how should Typedef go about making foo() do the right thing? Even with compiler support, this is impossible - the source of S.foo is simply not available, and it doesn't take the address of the static data as a parameter anywhere.
>
> But isn't foo scoped somehow?
> I mean, if foo is part of a type, then either you have to write s.foo, or S.foo. And if the address of a static belongs to a type, shouldn't this resolve the ambiguities?

Not really, since D doesn't have a concept of an address associated with a type, only with instances of it. So when you use a static array, the address is hard-coded.

--
  Simen

On Monday, 12 February 2018 at 09:37:56 UTC, Simen Kjærås wrote:
>
> Not really, since D doesn't have a concept of an address associated with a type, only with instances of it. So when you use a static array, the address is hard-coded.
>
> --
>   Simen

Ok... so the query on ptr on a static is not to be allowed? And the fact I can perform it is a bug?

On Monday, 12 February 2018 at 09:58:13 UTC, Alex wrote:
> On Monday, 12 February 2018 at 09:37:56 UTC, Simen Kjærås wrote:
>>
>> Not really, since D doesn't have a concept of an address associated with a type, only with instances of it. So when you use a static array, the address is hard-coded.
>>
>> --
>>   Simen
>
> Ok... so the query on ptr on a static is not to be allowed? And the fact I can perform it is a bug?

I'm sorry, I was apparently unclear. When I said 'static array' above, I meant 'static member'.

Since we've been using arrays in our examples, there could be conflation of ideas there. The fact that you can access (and even modify) the static member's .ptr property (as in S.arr.ptr = [1,2,3].ptr), doesn't mean you can change the address of the array itself (the static data in S). This can be shown by writeln(&S.arr), which will not change.

When you call a static method, as the one in this example:

struct S {
    static int[] arr;
    static void foo() { arr[0]++; }
}

unittest {
    S.foo();
}

No pointer is being passed to foo - it's exactly equivalent to this code:

module test;
int[] arr;
void foo() { arr[0]++; }

unittest {
    foo();
}

Likewise, when a non-static method modifies a static member, it doesn't need to look up the address of the static member - its address is hard-coded.

As an example, try this:

struct S {
   static int n1;
   int n2;
}

unittest {
    import std.stdio;
    S s1;
    S s2;
    // These should be equal:
    writeln(&s1.n1);
    writeln(&s2.n1);
    // These should be different:
    writeln(&s1.n2);
    writeln(&s2.n2);
}

--
  Simen

On Monday, 12 February 2018 at 11:25:40 UTC, Simen Kjærås wrote:
> I'm sorry, I was apparently unclear. When I said 'static array' above, I meant 'static member'.
>
> Since we've been using arrays in our examples, there could be conflation of ideas there. The fact that you can access (and even modify) the static member's .ptr property (as in S.arr.ptr = [1,2,3].ptr), doesn't mean you can change the address of the array itself (the static data in S). This can be shown by writeln(&S.arr), which will not change.
>
> When you call a static method, as the one in this example:
>
> struct S {
>     static int[] arr;
>     static void foo() { arr[0]++; }
> }
>
> unittest {
>     S.foo();
> }
>
> No pointer is being passed to foo - it's exactly equivalent to this code:
>
> module test;
> int[] arr;

/*
yeah... just saw it in the AST-output. However, even if this is rewrited, I cannot reference to the arr as
.arr
I have to write
S.arr
*/

> void foo() { arr[0]++; }
>
> unittest {
>     foo();
> }
>
> Likewise, when a non-static method modifies a static member, it doesn't need to look up the address of the static member - its address is hard-coded.
>
> As an example, try this:
>
> struct S {
>    static int n1;
>    int n2;
> }
>
> unittest {
>     import std.stdio;
>     S s1;
>     S s2;
>     // These should be equal:
>     writeln(&s1.n1);
>     writeln(&s2.n1);

// sure, this is because the type of s1 and s2 is the same.

>     // These should be different:
>     writeln(&s1.n2);
>     writeln(&s2.n2);
> }
>
> --
>   Simen

It is even worse, then I thought. Let us simplify our examples a little bit:

/// --- code --- ///
import std.typecons;

struct S { static int i; }
alias T = Typedef!S;
struct U { static int i; }

static assert(is(typeof(S.i) == int));
static assert(is(typeof(T.i) == void));

void main()
{
	S.i = 42;
	assert(U.i != S.i);
}
/// --- code ends --- ///

So... I'm starting to see your point now, I think.

What I expected from the Typedef was an ability to "templatify" a type ad-hoc. I wanted to say, well, I have a dedicated type and some different manifestations of it which I define by a Typedef.
After that, I could write some functions for different Typedefs being sure, that only the right types would be addressed by the functions, as specified in the example of Typedef.

However, as I can see, the definition of "static" takes advantage and heaves the according member away. Not only away from instances, but also from types (which is yeah... well... lets call it unexpected :) )

However, if I define another type manually, this is not the case.
So, static behaves differently on Typedefs, then on different types, defined manually.