What's the purpose of the restriction of alias in the specs -- 'Aliases cannot be used for expressions'; it prevents some useful things like this:

  int[2] nodes;
  alias nodes[0] left;
  alias nodes[1] right;

which currently has to be written in a much more hackish way:

  union {
    int[2] nodes;
    struct {
       int left;
       int right;
    }
  }

This is less reliable because if you decide to change the datatype of nodes, you could easily stuff up:

  union {
    long[2] nodes;
    struct {
       int left; // oops, forgot to change this. Now we've sliced the first value
       int right;
    }
  }

(Alternatively, you could implement this in an even more verbose way, which doesn't support things like left++:
   int[2] nodes;
   int left() { return nodes[0]; }
   int left(int val) { return nodes[0] = val; }
   int right() { return nodes[1]; }
   int right(int val) { return nodes[1] = val; }
)

It could also be used for function forwarding, as Frank Benoit requested earlier ('Feat. RQ: delegation alias'):

  class Foo
  {
    void DoSomething() {...}
  }

  class FooHandle
  {
    Foo myFoo;
    alias myFoo.DoSomething DoSomething;
  }


Maybe someone can explain why this restriction is necessary.

Cheers,

Reiner

Reiner Pope wrote:
> What's the purpose of the restriction of alias in the specs -- 'Aliases cannot be used for expressions'; it prevents some useful things like this:
> 
>   int[2] nodes;
>   alias nodes[0] left;
>   alias nodes[1] right;
> 
> which currently has to be written in a much more hackish way:
> 
>   union {
>     int[2] nodes;
>     struct {
>        int left;
>        int right;
>     }
>   }
> 
> This is less reliable because if you decide to change the datatype of nodes, you could easily stuff up:
> 
>   union {
>     long[2] nodes;
>     struct {
>        int left; // oops, forgot to change this. Now we've sliced the first value
>        int right;
>     }
>   }
> 
> (Alternatively, you could implement this in an even more verbose way, which doesn't support things like left++:
>    int[2] nodes;
>    int left() { return nodes[0]; }
>    int left(int val) { return nodes[0] = val; }
>    int right() { return nodes[1]; }
>    int right(int val) { return nodes[1] = val; }
> )
> 
> It could also be used for function forwarding, as Frank Benoit requested earlier ('Feat. RQ: delegation alias'):
> 
>   class Foo
>   {
>     void DoSomething() {...}
>   }
> 
>   class FooHandle
>   {
>     Foo myFoo;
>     alias myFoo.DoSomething DoSomething;
>   }
> 
> 
> Maybe someone can explain why this restriction is necessary.

alias has to do with symbols in the symbol table.
At least that's the definition, IIRC.

Although I'm sure it can either be extended to include what you propose, or a new keyword can be introduced for that purpose.

> 
> Cheers,
> 
> Reiner

Reiner Pope wrote:
> What's the purpose of the restriction of alias in the specs -- 'Aliases cannot be used for expressions'; it prevents some useful things like this:
> 
>   int[2] nodes;
>   alias nodes[0] left;
>   alias nodes[1] right;
> 
> which currently has to be written in a much more hackish way:
> 
>   union {
>     int[2] nodes;
>     struct {
>        int left;
>        int right;
>     }
>   }
> 
> This is less reliable because if you decide to change the datatype of nodes, you could easily stuff up:
> 
>   union {
>     long[2] nodes;
>     struct {
>        int left; // oops, forgot to change this. Now we've sliced the
> first value
>        int right;
>     }
>   }
> 

you could do this:

  template KT(T)
  {
    union KT
    {
      T[2] nodes;
      struct
      {
        T left;
        T right;
      }
    }
  }

  alias KT!(int) K;

roel

Reiner Pope wrote:

> What's the purpose of the restriction of alias in the specs -- 'Aliases cannot be used for expressions'; it prevents some useful things like this:
> 
>   int[2] nodes;
>   alias nodes[0] left;
>   alias nodes[1] right;

Looks kinda scary. It resembles me of C's textual macros which are somewhat dangerous and may introduce hard to debug errors.

-- 
AKhropov

rm wrote:
> Reiner Pope wrote:
> 
>>What's the purpose of the restriction of alias in the specs -- 'Aliases
>>cannot be used for expressions'; it prevents some useful things like this:
>>
>>  int[2] nodes;
>>  alias nodes[0] left;
>>  alias nodes[1] right;
>>
>>which currently has to be written in a much more hackish way:
>>
>>  union {
>>    int[2] nodes;
>>    struct {
>>       int left;
>>       int right;
>>    }
>>  }
>>
>>This is less reliable because if you decide to change the datatype of
>>nodes, you could easily stuff up:
> 
> 
> you could do this:
> 
>   template KT(T)
>   {
>     union KT
>     {
>       T[2] nodes;
>       struct
>       {
>         T left;
>         T right;
>       }
>     }
>   }
> 
>   alias KT!(int) K;
> 
> roel

Or in this case he's not even after a template, so just
  union {
    alias int NodeID;
    NoteID[2] nodes;
    struct {
       NodeID left;
       NodeID right;
    }
  }

But, I see your point, Reiner.  'alias foo[1] bar' expresses the intent of the programmer more clearly here than union, and doesn't have the typesafety issues.

--bb

Reiner Pope wrote:
> What's the purpose of the restriction of alias in the specs -- 'Aliases cannot be used for expressions'; it prevents some useful things like this:
> 
>   int[2] nodes;
>   alias nodes[0] left;
>   alias nodes[1] right;

How about:

	auto left = &nodes[0];
	auto right = &nodes[1];

Or:

	auto left = (){ return nodes[0]; }
	auto right = (){ return nodes[1]; }

> It could also be used for function forwarding, as Frank Benoit requested earlier ('Feat. RQ: delegation alias'):
> 
>   class Foo
>   {
>     void DoSomething() {...}
>   }
> 
>   class FooHandle
>   {
>     Foo myFoo;
>     alias myFoo.DoSomething DoSomething;
>   }

Or:
	auto DoSomething = &myFoo.DoSomething;


> Maybe someone can explain why this restriction is necessary.

Walter Bright wrote:
> Reiner Pope wrote:
> 
>> What's the purpose of the restriction of alias in the specs -- 'Aliases cannot be used for expressions'; it prevents some useful things like this:
>>
>>   int[2] nodes;
>>   alias nodes[0] left;
>>   alias nodes[1] right;
> 
> 
> How about:
> 
>     auto left = &nodes[0];
>     auto right = &nodes[1];

test.d(13): non-constant expression & nodes
test.d(14): non-constant expression (& nodes+4)

> 
> Or:
> 
>     auto left = (){ return nodes[0]; }
>     auto right = (){ return nodes[1]; }

  auto left = (){ return nodes[0]; };
  auto right = (){ return nodes[1]; };

test.d(15): delegate properties.Props.__dgliteral1 literals cannot be class members
<COMPILER CRASH>

> 
>> It could also be used for function forwarding, as Frank Benoit requested earlier ('Feat. RQ: delegation alias'):
>>
>>   class Foo
>>   {
>>     void DoSomething() {...}
>>   }
>>
>>   class FooHandle
>>   {
>>     Foo myFoo;
>>     alias myFoo.DoSomething DoSomething;
>>   }
> 
> 
> Or:
>     auto DoSomething = &myFoo.DoSomething;

test.d(32): non-constant expression &(myFoo).DoSomething


--bb

RE: errors

I wrote those on the assumption they'd be inside a function. As globals, they won't work, but in general things line int[2] shouldn't be globals.

Walter Bright wrote:
> RE: errors
> 
> I wrote those on the assumption they'd be inside a function. As globals, they won't work, but in general things line int[2] shouldn't be globals.

I think the point was that these workarounds aren't sufficient.

Walter Bright wrote:
> RE: errors
> 
> I wrote those on the assumption they'd be inside a function. As globals, they won't work, but in general things line int[2] shouldn't be globals.

Those were in a class.

--bb