typedef behavior

[Alex]

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.