>If it *was* implemented, shouldn't it be done
>the same way as it's done with arguments, i.e.
>with the "in", "inout" and "out" designators ?

'inout' sounds OK for function parameters or return types; but a bit strange in other place (e.g. local variable, class attribute) to denote reference type.

>I'm not sure what the use of such references
>would be, outside of parameters, though ?

As in the original example, you can use it as local variable to reduce uncessary look-ups:

ref rval = map[key];  // only one lookup is needed
rval += 3;

otherwise:

val = map[key];    // two look-ups
map[key] = val+3;

(unless you also provide "+=" operator for map; but operator overloading cannot exhaustively provide all the possible functionality of direct access through reference)

> but maybe some kind of references would be good ?

That's what I think.  For example, in C++ STL, all the index operators return reference type, so you can manipulate the index-ed data directly without calculate its index everytime you want to access/modify it.

> Actually alias sort of works for this already,
> just that you can't reuse the same name twice:
>
> >   alias i r;
> >   alias j r;
> "declaration main.r is already defined"
..

>If the new declaration *was* just an alias, then
>maybe D needs "unalias" like the "sh" shell has ?
>
>> void main()
>> {
>>   int i, j;
>> 
>>   alias i r;
>>   r = 3;
>>   assert(i == 3);
>> 
>>   unalias r; // <-- new compiler directive
>> 
>>   alias j r;
>>   r = 3;
>>   assert(j == 3);
>> }
>
>Where unalias simply makes a previous alias
>declaration "disappear" from the name space ?
>
>Without it, it throws an error when reusing :
>> declaration main.r is already defined

I believe (not sure), the current alias in your quote is just syntax sugar, it's not different from  #define in C++:

#define j main.r

If we go back to the map example:

#define rval map[key]

then multiple look-ups still happen.

Actually now I think use 'alias' maynot be a good notation choice for reference. Since it has been used for syntactical sugar already.  If we have both value-assignment and (semantic) reference-assignment, that will be great.  As to the notation, maybe we can use another keyword 'ref', or just use C++'s &?

no@where.com wrote:

> 'inout' sounds OK for function parameters or return types; but a bit strange in
> other place (e.g. local variable, class attribute) to denote reference type.

Maybe it needs a synonym ? Like your suggested "ref".

I always found the C++ syntax of type& to be confusing...

> As in the original example, you can use it as local variable to reduce uncessary
> look-ups:
> 
> ref rval = map[key];  // only one lookup is needed
> rval += 3;
> 
> otherwise:
> 
> val = map[key];    // two look-ups
> map[key] = val+3;
> 
> (unless you also provide "+=" operator for map; but operator overloading cannot
> exhaustively provide all the possible functionality of direct access through
> reference)

I think the currently suggested approach is to use pointers...

Either the old:

  assert(key in map);
  type* val = &map[key];
  *val += 3;

Or the new syntax:

  type* val = key in map;
  assert (val != null);
  *val += 3;

"in" was changed from a bit to a pointer, with DMD version 0.107

Or you could make it use D "references" instead,
by moving the code in question into a function:

  void do_stuff(inout type val) { val += 3 };
  do_stuff(map[key]);

And hope that the compiler is smart enough to inline ?


There's plenty of interesting info at http://c2.com/cgi/wiki?NoPointers

Already seems to be three fighting sides of the war: C, C++ and Java...

--anders

>Actually alias sort of works for this already,
>just that you can't reuse the same name twice:
>
>>   alias i r;
>>   alias j r;
>"declaration main.r is already defined"

It's not the same. We want to be able to use references as return type.


>> I just replaced on alias with ref and the alias-operator with := and to me it looks pretty understandable.
>
>Unless you had to look at Pascal or Ada at some point in your life...
>
>They use := for assignment (=) and a single = for equality (==).

I know Pascal ans some other languages that use these operator names.
Well you know = for assignment in D. And I needed another name for a different
kind of assignment. So I choosed :=, because many languages use it for
assignment.

[...]
>You meant to write "r = &i", since the above code does not compile.
Ups, yes.


>> Of course, it's the same as pointers, but you don't have to dereference it.
>
>I know the C++ references. No dereferencing, no nullpointers. But still with a high potential for confusion, if used heavily...
What about D-references? Every class-type is a reference-type!


>I think the inout parameters and lack of copy constructors makes D not need them, but maybe some kind of references would be good ?

We already have them: pointers. The only problem was, that you have to manually dereference them.

Ah, what about this:

# void foo()
# {
#    int i, j;
#    ref int r;
#
#    &r = &i;  // r is now refering to i
#    r = 3;    // assert( i == 3 );
#
#    &r = &j;   // r is now refering to j;
#    r = 3;    // assert( j == 3 );
# }

so '&somereference' is an l-value if 'somereference' is a reference? That looks way better to me then the ':='.


-- Matthias Becker