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 {

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
I have to write

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

unittest {

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:

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

    // These should be different:


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.

Reply via email to